Hi, the use-case sounds very reasonable to me, e.g. when the implementation of a web-service sends out a serialized persistent object, receives back the object with changes, and now needs to apply the changes to the database.
Since makePersistent() is handling attaching so far, this could be the place to transition such an object from transient to persistent-dirty (with all fields marked dirty). Maybe an exception should be thrown when there already is a persistent-dirty object with the same id managed by the same PM. Since that would mean change of behaviour (somebody might rely on inserting new objects when calling makePersistent() on transient instances that have an id value), there probably should be an additional setMergeOnMakePersistent(boolean) or something like that, defaulting to the old behaviour. This would only work for application-identity. For datastore-identity, some new method(s) would be required to determine the objects' ids, as Pavel suggested. Regards, Jörg Pavel wrote: > Hi, > > This email is a continuation of discussion started at > http://www.jpox.org/servlet/forum/viewthread?thread=4893&lastpage=yes . > > Quick summary is that there is a number of [I believe fairly strong] cases > where application deals with transient objects which somehow correspond to > already persisted objects. > > These instances have updated state in there, but persisting that state takes > extra code and datastore hits, just to preload persistent counterpart and > copy properties. > > My question is whether it is possible and makes sense for JDO to support > "attachment" of transient objects, so that > a) all the steps required for such "attachment" become duty of JDO > implementation, not client code and > b) reads before update are optimized (e.g. one read for collection) or > eliminated at all. > > Code-wise I imagine methods like > > // Application identity > <T> T attachTransient(T instanceWithAppIdentity); > <T> Collection<T> attachTransientAll(Collection<T> > instancesWithAppIdentity); > > // Datastore identity - client code provides id explicitly to let JDO > identify persistent counterpart > <T> T attachTransient(T instanceWithDSIdentity, Object id); > <T> Map<Object, T> attachTransientAll(Map<Object, T> > instancesWithDSIdentity); // Map is {id => instance} > > What do you think? > > Thanks, > Pavel > > -- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550