Re: [hibernate-dev] Unsaved values

From digging into the code, it looks like the only place where things may need to be processed differently is for composite/component IDs. o.h.mapping.SimpleValue.nullValue is initialized to null. There are 2 places in the old mapping code where SimpleValue.setNull( "undefined" ) is called when binding from annotations: - in o.h.cfg.BinderHelper.makeIdGenerator(), if the generator is "assigned" [1] - in o.h.cfg.annotations.PropertyBinder.bind(), if isXToMany or entityBinder.wrapIdsInEmbeddedComponents() are true [2]. I believe isXToMany is true if the ID is actually a many-to-one (like HBM key-many-to-one). It makes sense to me that the unsaved value would be "undefined" in this case. The same is true for HBM key-many-to-one, unless some other unsaved-value is specified, so there's no inconsistency there. I'm not sure of the use cases where entityBinder.wrapIdsInEmbeddedComponents() is true. An inconsistency with HBM could arise if the generator is not "assigned" and both isXToMany and entityBinder.wrapIdsInEmbeddedComponents() are false for a use case that corresponds with an HBM composite-id. Can that happen? If so, the unsaved value for annotations would end up as null and the unsaved value for HBM would be "undefined" (unless some other value was specified). [1] https://github.com/hibernate/hibernate-orm/blob/metamodel/hibernate-core/... [2] https://github.com/hibernate/hibernate-orm/blob/metamodel/hibernate-core/... ----- Original Message ----- > From: "Steve Ebersole"<steve(a)hibernate.org> > To: "Gail Badner"<gbadner(a)redhat.com> > Cc: "Hibernate hibernate-dev"<hibernate-dev(a)lists.jboss.org> > Sent: Thursday, March 29, 2012 8:51:13 AM > Subject: Re: [hibernate-dev] Unsaved values > > I'll definitely take a look as soon as I get some time (currently > busy > working through some JPA 2.1 stuff). But in the meantime maybe you > could do a plain English write-up describing the differences you see > here between hbm and annotations that led you to look to these > strategies so that we can comment and get you moving forward more > quickly... > > In general, the thing we need to guard against here is duplicating > code. The existing binders duplicate tons of stuff and its a > maintenance nightmare. So for example, the end-game determination > for > unsaved-value in hbm is to instantiate the entity an reflect its > actual > newly-instantiated value. I think annotations does the same. So > that > code should be outside of hbm/annotations. Unless we decide as a > group > that its "ok" for sources (hbm/annotations) to share that code > (subclass, delegation, etc) from its particular strategy. > > On Thu 29 Mar 2012 02:25:35 AM CDT, Gail Badner wrote: >> At the team meeting in Austin, I remember discussion about cases >> where different "strategies" were needed to process values >> obtained from annotations and hbm.xml sources. I can't remember if >> we discussed unsaved values, but it seems to me that this is one >> case where this is needed. >> >> I created a pull request for dealing with unsaved values: >> https://github.com/hibernate/hibernate-orm/pull/298. >> >> Please take a look and provide feedback to let me know if I'm on >> the right track. >> >> Thanks, >> Gail >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > steve(a)hibernate.org > http://hibernate.org >