An even better (and much easier to implement) approach might be to simply
skip the nullification if the identifier of the transient instance indicates
that it already exists on the database.
Thats easy to implement. You wanna take a stab at it Andrea?
Gavin
----- Original Message -----
From: "Andrea Aime" <aa...@li...>
To: <hib...@li...>
Sent: Thursday, October 10, 2002 11:31 PM
Subject: [Hibernate] Long transactions, object update and many-to-one...
> Hi everybody,
> I have a little feature request/question for you.
> Suppose you have two beans Customer, Country, and Customer
> has a many-to-one property of type Country (not-null). In a long
> transaction I load all of the Countries to fill in a JCombobox
> in a form to input a new Customer. Then, when the user confirms
> the insertion, I open a new session and try to save the Customer,
> which has a reference to a Country loaded in the previous section...
> this will not work, because Hibernate nullifies the reference
> to the Country object unless I reload it in the new Session.
> What I wonder is, why this reloading work cannot be done by
> Hibernate itself? The nullifyTransientReferences method in SessionImpl
> walks thru the objects property and determines if the property
> is an Entity, then discards it if it's Transient... why cannot
> it have a look at the entity identifier, see if it's not null,
> and in that case load this object without the need of user's support?
> Of course this requires that the referenced entity has the
> "unsave-value" property set...
> What do you think?
> Best regards
> Andrea Aime
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
|
