Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (athena.apache.org: domain of
 joerg.von.frantzius@artnology.com designates 80.67.29.23 as permitted sender)
Message-ID: <48AD77AA.5090308@artnology.com>
Date: Thu, 21 Aug 2008 16:11:54 +0200
From: Joerg von Frantzius <joerg.von.frantzius@artnology.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080720)
MIME-Version: 1.0
To: jdo-user@db.apache.org
CC: Apache JDO project <jdo-dev@db.apache.org>
Subject: Re: Updating datastore with transient instance
References: <f2ace7ab0805311518v7117795bp660f56f7bf5a477a@mail.gmail.com>
In-Reply-To: <f2ace7ab0805311518v7117795bp660f56f7bf5a477a@mail.gmail.com>
Content-Type: multipart/mixed;
 boundary="------------000309000901070100050201"

--------------000309000901070100050201
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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


--------------000309000901070100050201--