[hibernate-dev] Unsaved values

Fri Mar 30 14:49:21 EDT 2012

I have verified that "assigned" generators default to "undefined" as the id-based unsaved-value for both HBM and annotations so that part is fine.

Thanks for the info. I've convinced myself that unsaved values can be processed the same way for HBM and annotations.

Thanks,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Hibernate hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Friday, March 30, 2012 8:08:20 AM
> Subject: Re: [hibernate-dev] Unsaved values
> 
> unsaved-value is tricky in many ways.  In case anyone is not aware,
> there really is just one unsaved-value strategy for each entity.  It
> just happens that unsaved determination could be based on id, or
> based
> on version; that is why we have 2.  Outside of an explicitly
> user-provided value, "undefined" at the id level should result in
> using
> the version-based strategy.  "undefined" simply means that Hibernate
> is
> supposed to physically go query the database to determine if that
> particular id value already exists (detached) or not
> (transient/unsaved).  The end goal is to avoid that as often as
> possible.
> 
> I am pretty sure that all "assigned" generators[1]  default to
> "undefined" as the id-based  unsaved-value.  I am certain that is the
> case with HBM.  I would think that is the desired behavior with
> annotations as well.  Again, this is outside of the user explicitly
> providing an unsaved-value.
> 
> EntityBinder.wrapIdsInEmbeddedComponents() is dealing with what
> Hibernate used to call "embedded composite ids" way before JPA came
> along and misused that term :)  Basically the notion of an entity
> that
> defines a composite identifier but does not use a component to
> represent the id value.  It is setting that flag whenever it
> processes
> an entity that does not define an @IdClass.
> 
> Anyway, my gut tells me that any differences between annotations and
> hbm in terms of unsaved-value are due to code duplication rather than
> a
> conscious decision to have them be different.
> 
> 
> [1]  and all composite ids are typically "assigned", unless the user
> specifies generator for the component.  I forget offhand how "partial
> generation" of composite ids are viewed in terms of generator, but my
> guess is that they are always deemed "assigned".
> 
> 
> 
> On Thu 29 Mar 2012 07:12:40 PM CDT, Gail Badner wrote:
> >  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/src/main/java/org/hibernate/cfg/BinderHelper.java#L526
> >
> > [2]
> > https://github.com/hibernate/hibernate-orm/blob/metamodel/hibernate-core/src/main/java/org/hibernate/cfg/annotations/PropertyBinder.java#L218
> >
> > ----- Original Message -----
> >> From: "Steve Ebersole"<steve at hibernate.org>
> >> To: "Gail Badner"<gbadner at redhat.com>
> >> Cc: "Hibernate hibernate-dev"<hibernate-dev at 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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >> --
> >> steve at hibernate.org
> >> http://hibernate.org
> >>
> 
> --
> steve at hibernate.org
> http://hibernate.org
> 