[hibernate-dev] Some thoughts on possible Binder changes

[Hardy Ferentschik]

On 12 Jan 2014, at 18:56, Steve Ebersole <steve at 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.


> 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.

> 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)

+1 to anything which can break up the Binder. 


> 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

Sounds reasonable. As always the devil is probably in the detail. I don’t know enough about 
the corner cases and complications to point out where this approach would cause problems. 

> 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).

> 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.


—Hardy