1:55 p.m.
Thanks for the response. See inline...
On Sat, Apr 12, 2014 at 1:15 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
On 12 Jan 2014, at 18:56, Steve Ebersole <steve(a)hibernate.org> wrote:
> The Background
...
Thanks Steve, for this really nice summary. It is always good to share
some basic design/implementation
details.
> 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.
What do you mean by "completes". How do you know that the
EmbeddableBinding is complete.
For embeddables, this boils down to its sub-attributes being fully bound.
Ultimately we need to be able to generate the Hibernate Type. So looking
at my example below, ultimately what we care about in regards to
Person#address is the resolved Type for that attribute.
So here, "completes" is the verb form; the idea being simply.. was the
attribute we just finished processing the last unresolved sub-attribute for
a embeddable; did it "complete" the embeddable in terms of all its
sub-attributes now being done.
As for how we know that, that depends. In the existing Binder code we
literally iterate the attributes making up the embeddable and see if the
Type for all those sub-attributes has been resolved.
See
org.hibernate.metamodel.internal.binder.Binder#completeCompositeAttributeBindingIfPossible
for the current process.
I am suggesting this change to use events as outlined below.
> 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 :)
For what it's worth, Strong had once the same idea. Instead of rechecking
and looping he also wanted to
introduce some sort of event based processing. I thought the idea sounded
promising.
I am not sure how far he got or whether he even started. I think this was
not long before metamodel was put on
ice fore a while.
To be honest, I had the same suggestion for HBMBinder as well even back in
the day to get out of second passes. I think its a somewhat natural
paradigm for the type of problem domain here.
> 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.
It can not get much worse than following the 4k Binder as it stands now.
Event based processing
can sometimes be tricky. Maybe it would help in this case to document the
approach and
algorithm and the main actors. Either in the javadocs or maybe even better
in an topical guide (more
dev centric in this case).
True with the "it can't get much worse" aspect. I think sequential
processing is fine/great if the thing you are doing is relatively simple.
I think its safe to say that this is not simple :)
> Anyway... thoughts? comments?
For me it is also a question of time and resources. I agree that cleaning
up the binding code would be
awesome, but on the other hand I thought most of the details for binding
the new metamodel had been
sorted out by now. Is it worth rewriting now. On the other hand, if there
are real issues with the code
it might be worth the try.
I think "cleaning up" and "paradigm shift" are different beasts. Yes
cleaning up can be done any time (even later) relatively easily.
Completely shifting the underlying principles by which you attack a
problem is altogether different in my mind; I think the approach is best
ironed out from the onset.
That being said, a lot of the actual functionality is already in place.
Its just a matter of organizing it slightly differently in most cases.
As for most cases being handled... well the 492 *uses* (not tests mind you,
uses equate to one or more tests) of FailureExpectedWithNewMetamodel would
beg to differ. And that's not counting envers in any way which currently
has tons of failures because of the shift to metamodel. Lots of things
simply do not work yet in metamodel.