Hello all, This will probably be very useful in situations where we do not have full control of the object in question. For example Axis is a very good framework for implementing web services, as well as Java -> XML & XML -> Java binding. However without modification of Axis, the returned Java object will always be a new object (as far as Hibernate is concerned). If we are using long running async messaging with Axis we may not even have the original object to modify. Thus having the saveOrUpdateCopy method will allow for directly saving the copy with the updates to the database. The saveOrUpdateCopy is in-efficient compared to saveOrUpdate, but does the same work that I would have to do in order to save the updated data to the DB. And as always the more you can let a framework do the better.
What are the requirements for the copy to be correctly persisted into the database? Just the ID to be the same? Would it be more efficient to not retrieve the original object from the database? I.E. if this object is a copy just put it in the cache instead of the original, and also call update on the database. This would save the retrieval of the database version of the object. What happens in the current implementation if the copy object is not fully filled out, but the database version is? For example, lets say I have a parent object and a child object. The database version of both objects are fully filled with data. My "copy" parent does not have the relationship to the child object because I never sent that as part of the web service call, and I let the web service contruct the "copy" parent. If I call saveOrUpdateCopy with the parent object as it is, and then immediately retrieve that object back from the db with Hibernate will the retrieved object have the child or not? Also, if my parent object has some fields filled in, and other fields are null, but the database version has all fields filled in, what will be in the database after the storeOrUpdateCopy call? Will the "copy" be there, and some fields null? Or will the original version be there, with the data from the copy overriding the fields it had data for? Later Rob > Heres a list of some of the most common problems we get: > > * bad unsaved-value mappings > * problems with cascade save for composite-id classes > * "an object with this id was already associated with the session" > > It turns out that they can all be addressed by adding a new method > to the session. This method looks a little bit like saveOrUpdate() > except that instead of relying completely upon the guess made from > the unsaved-value mapping, it always hits the database to try and > load up the existing object before updating it (or grabs an already > loaded object from the session cache). The new state is then /copied/ > onto the loaded object and the loaded object is returned to the user. > We never get the exception listed above, because we don't try to add > the given object to the cache. If no object is returned from the > database, we save the given object. > > Cascade semantics for this operation are the same as for > saveOrUpdate(). > > This approach has two enormous disadvantages: > > (1) it breaks == from the user's POV > (2) it is much less efficient than just doing an update > > But, as long as we have both options, all is good. > > (Actually, this is a bit of an improved implementation of what has > been proposed for JDO2.) > > Gentlemen, I give you: saveOrUpdateCopy() > > Yes, it is not the most inspired naming ever, but I can't think > of anything better. JDO2 will call this operation reattach() or > reassociate() ... which is an absolutely horrible choice, since > the only thing it does /not/ do is reattach/reassociate the > given instance with the session. (Unlike lock() or update(), > both of which /do/ perform reassociation.) > > This is mainly provided to > > (a) help out people who are trying to make composite-id stuff work > (b) solve problems for people who try to do this: > > Foo foo =.....; > Foo oldFoo = session.get( Foo.class, foo.getId() ); > if (oldFoo!=null) doSomethingWithOldFoo(oldFoo); > session.saveOrUpdate(foo); //ERROR! > > Now they can just happily do: > > Foo foo =.....; > Foo oldFoo = session.get( Foo.class, foo.getId() ); > if (oldFoo!=null) doSomethingWithOldFoo(oldFoo); > foo = session.saveOrUpdateCopy(foo); > > I think this is worth the effort. You can find it in CVS. > > -- > Gavin King > JBoss Group > +61 410534454 > http://hibernate.org > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > hibernate-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
