Also inline... ----- Original Message ----- > From: "Steve Ebersole" <st...@hibernate.org> > To: "Hardy Ferentschik" <ha...@hibernate.org> > Cc: "Hibernate" <hibernate-dev@lists.jboss.org> > Sent: Saturday, April 12, 2014 11:55:28 AM > Subject: Re: [hibernate-dev] Some thoughts on possible Binder changes > > Thanks for the response. See inline... > > > On Sat, Apr 12, 2014 at 1:15 PM, Hardy Ferentschik > <ha...@hibernate.org>wrote: > > > > > On 12 Jan 2014, at 18:56, Steve Ebersole <st...@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. > >
Yes, this is what it does. I agree there are better ways to deal with it. I thought the priority was to get functionality working ASAP. It was the easiest way to get it working at the time, and I figured we'd refine after the alpha. > > 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. > I also remember Strong mentioning an events approach, but I think it was after embeddables were already working. > > > > > > > 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 had also assumed that breaking up the Binder would be post-alpha. > > 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. > I agree a paradigm shift is best as soon in the process as possible. > 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. I would say that most things do work. Strong and I kept track of what was left by maintaining this document: https://github.com/hibernate/hibernate-orm/wiki/Failing-metamodel-tests . Steve, are you keeping this up-to-date? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
