db-jdo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: Updating datastore with transient instance
Date Thu, 21 Aug 2008 14:11:54 GMT
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


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message