HEM "packaged" tests
by Steve Ebersole
With my latest Scanner changes as outlined in the earlier email there is
one failure in the HEM "packaged" tests that I simply cannot explain why it
was previously considered valid.
The test
is org.hibernate.jpa.test.packaging.PackagedEntityManagerTest#testCfgXmlPar.
The test builds a PAR (via ShrinkWrap) and then tries to use it. The
persistence.xml simply points to a cfg.xml. The cfg.xml names 4 classes.
But the PAR only bundles 2 of them. The test fails because Binder cannot
find the other 2 classes. Should this be valid? Should the cfg.xml inside
a PAR be allowed to name classes not contained in the PAR? Obviously if
the test is allowed to pick up all classes on the "real test classpath" the
test will pass.
11 years, 7 months
Fwd: GitHub repo for demo projects
by Martin Braun
+1
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
-----Original Message-----
From: Davide D'Alto <daltodavide(a)gmail.com>
To: hibernate-dev <hibernate-dev(a)lists.jboss.org>
Sent: Mon, Apr 28, 2014 5:29 pm
Subject: Re: [hibernate-dev] GitHub repo for demo projects
+1
On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer(a)redhat.com> wrote:
> +1 from me. I have several to contribute as well from various ORM
> presentations.
>
> https://github.com/brmeyer/HibernateDemos
>
> ----- Original Message -----
> From: "Gunnar Morling" <gunnar(a)hibernate.org>
> To: hibernate-dev(a)lists.jboss.org
> Sent: Monday, April 28, 2014 10:49:19 AM
> Subject: [hibernate-dev] GitHub repo for demo projects
>
> Hi,
>
> Together with Sanne I've been creating a demo app which shows some features
> of Hibernate OGM.
>
> Right now this lives under my personal account on GitHub, but IMO it'd make
> sense to move it somewhere under https://github.com/hibernate/ to make it
> more visible, encourage re-use and contributions by others etc.
>
> What do you think about creating a repo under the hibernate organization
> such as "hibernate-demos" which could host this and other demos for our
> projects in the future? Or would it even make more sense on a per-project
> base ("hibernate-ogm-demos" etc.)?
>
> --Gunnar
>
> [1] https://github.com/gunnarmorling/ogm-hiking-demo
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11 years, 7 months
[OGM] Pull request job issues fixed
by Gunnar Morling
Hi,
The OGM pull request job is fine again now.
The issue was that I had configured it to use a private M2 repo (to avoid
conflicts with the master job) within the workspace which then ended up
being added to the distribution TAR which failed due to size constraints.
The repo lives at another place now to avoid this.
--Gunnar
11 years, 8 months
Meeting time
by Steve Ebersole
Now that Europe has had its time change, we should be back on for meeting @
10 am US Central TZ I think.
Does that time still works for everyone?
Also, does it make sense to set up the meeting based on a DST-neutral
calendar (so we avoid the different time changes)?
11 years, 8 months
5.0 metamodel binding
by Steve Ebersole
Gail,
I am working on some changes to metamodel and have come across some things
that I need your help deciphering in terms of things you do Binder. The
background is this...
At the moment all of metamodel binding completely mis-handles
MappedSuperclasses. The annotation source processor handles them somewhat,
but in a very unusable way; it basically flattens all MappedSuperclass info
into the nearest Entity. This is because the source package does not at
all support the definition of MappedSuperclass. And then of course
bindings do nothing with it, since it is not accounted for in source.
To add this support I plan on the following changes:
1) Move lots of the information currently defined by RootEntitySource into
EntityHierarchy. The identifier, version, etc is actually a function of
the hierarchy as a whole, so conceptually it makes more sense there anyway.
And that mirrors the way we modeled it in the binding spi.
2) Generalize the EntityHierarchy tree to allow mixing Entity and
MappedSuperclass sources. A MappedSuperclass source actually needs to be
defined.
3) Model MappedSuperclass in the binding spi as well.
Which leads to my confusion. I have no idea how to account for such
changes in the Binder code and its calls through various executors and
contexts. I really need some pointers here.
11 years, 8 months
Some thoughts on possible Binder changes
by Steve Ebersole
The Background
Binder deals with dependencies between things. An Entity cannot be fully
bound until its attributes and identifier are fully bound. An Embeddable
cannot be fully bound until its sub-attributes are fully bound. One Entity
might depend on another by nature of a "key many to one" or a "one to one"
or a "mappedBy" or... In short, there is a lot of dependency to the order
things must be bound.
Some of these dependencies are *a priori* in nature. Basic attributes
should be bound before embedded and associations. Attributes for a
Entity/Embeddable need to be fully bound before the Entity/Embeddable can
be considered complete. The Binder tries to handle these *a priori
*dependencies
simply by the order in which it processes things internally. This works
reasonably well.
The other dependencies are *a posteriori *in nature, in that we cannot
fully understand them in terms of ordering until we get into the processing
of the data. This includes "key many to one" or a "one to one" or a
"mappedBy" examples from above.
Turns out that binding of Entity and Embeddable are both functionally *a
posteriori* as well because of the fact that we first create those bindings
(as a shell if you will) and add the bindings for their attributes, etc
after the fact. So we can't understand that either are fully resolved
until after the fact. Not a huge deal, just pointing it out.
The Use Case
I have been working on completing identifier handling, especially in the
case of composite ids. As more "background" to where my thoughts came
from, let me walk y'all through how Binder currently deals with this stuff.
As I mentioned above, as part of its *a posteriori* handling, Binder
attempts to cycle through attributes based on their nature:
1. Process composites
2. Process simple/basic attributes
3. Process many-to-one
4. Process one-to-one
5. Process many-to-one (mappedBy)
6. Process one-to-one (mappedBy)
7. Process plural attributes
8. Process plural attributes (mappedBy)
In terms of dealing with composite ids, step (1) really just means creating
the Embeddable "shells" (the EmbeddableBinding instance). But at this
point the EmbeddableBinding is not done, we still need its attributes
"resolved" or "bound". To accomplish this, as Binder walks through the
rest of the steps, it continually checks whether the completion of the
attribute it just bound completes the binding of the Embeddable. So as it
is looping over every attribute, for each attribute it loops over every
known incomplete EmbeddableBinding and checks whether that attribute
"completes" the EmbeddableBinding and if so finalizes it's binding.
First thing I noticed is that that is a lot of looping (within looping).
While I am sure that has some performance impact, that is not really my
concern. My concern was more the non-definitive state of things being
resolved. Coming back to the EmbeddableBinding as a composite id... quite
a few of those steps rely on the id of an entity being fully resolved.
Events
Which got me to thinking about using events to signal the completion of
things, and the ability to listen for these events. Don't worry, I mean
events here as fairly light weight concept :)
Essentially the idea is to have producers and listeners and to have Binder
act as the bus. So let me apply this to the composite id case above as an
example. So we'd still have an initial step that creates the
EmbeddableBinding instances. It would use a EmbeddableBindingCreator
delegate (I was already in the process of breaking up the 4K line Binder
class to use some delegation) to do the EmbeddableBinding creation.
EmbeddableBindingCreator would also implement the "listener" contract for
AttributeBinding completion; as attributes are completed, if they are part
of an EmbeddableBinding we "check them off" and when an EmbeddableBinding
has no more unresolved sub-attributes we would finalize the
EmbeddableBinding. Here, EmbeddableBindingCreator would also play a
"producer" role; when the EmbeddableBinding is finalized, it would notify
the bus of that. And then registered listeners for that event could react.
Consider a nested composite (Embedded w/in an Embeddable):
@Entity
class Person {
...
@Embedded Address address;
}
@Embeddable
class Address {
...
@Embedded Zip zip;
}
@Embeddable
class Zip {
..
String code;
String plus4;
}
The initial step has EmbeddableBindingCreator create the
EmbeddableBinding(Person#address)
and the EmbeddableBinding(Person#address#zip). Additionally,
EmbeddableBindingCreator registers the sub-attribute roles making up each
EmbeddableBinding and keeps track of them (the "unresolved ones").
The second step processes basic attributes (note to self, ideally we should
make sure the nested simple attributes are ordered first here):
1) Say first we'd process Person#address#zip#code; we finalize it and fire
off the "attribute bound" event which EmbeddableBindingCreator gets
notified of. EmbeddableBindingCreator removes the Person#address#zip#code
attribute role from the unresolved attributes for
EmbeddableBinding(Person#address#zip). However, we see there is still more
unresolved sub-attributes, so nothing more to do.
2) Then we process Person#address#zip#plus4, finalize it and fire off the
"attribute bound" event which EmbeddableBindingCreator gets notified of.
EmbeddableBindingCreator removes the Person#address#zip#plus4 attribute
role from the unresolved attributes for
EmbeddableBinding(Person#address#zip). Now it sees that all of the
sub-attributes for EmbeddableBinding(Person#address#zip) are resolved, and
so finalizes EmbeddableBinding(Person#address#zip), firing off its own
event that the embeddable was finalized.
That event routes back to Binder, which directs it back to a listener for
the Person#address attribute (which was registered as waiting on the
EmbeddableBinding(Person#address#zip) as one of its attribute types). We
finalize that attribute, and fire its completion event which again
EmbeddableBindingCreator gets notified of... And so on
FYI, the finalization aspect is important because it signals when we are
able to resolve the Hibernate Type for things that refer to these.
Concerns
There are some concerns with such an approach. Here are the ones I had.
Maybe y'all have others?
First, there is the general pros/cons of sequential processing versus
event-driven processing. Some folks view event-driven processing as more
convoluted, harder to follow.
Another concern is cases where a "bi-directional dependency" exists, which
might lead to an indefinite wait. I do think adding some "finish" up step
at the end of the initial 1-8 steps is important where each
listener/producer is able to report things it is still waiting on.
Anyway... thoughts? comments?
11 years, 8 months
