You said
mapping a peer object in a different context
Our docs [1] say:
Each instance of a DataObject belongs to only one DataContext for the duration of the object
lifecycle. Sometimes there maybe a need to transfer a list of objects from one DataContext to
another. The goal of this operation is to be able to use such objects in relationships with objects
of the target DataContext. Most common use for this feature is the following. An application may
have a "shared" DataContext that is used to fetch "static" read only lookup
data. To avoid fetching the same data over and over again for each session, objects from the shared
DataContext can be transferred to a session DataContext by calling DataContext.localObject():
A slightly confusing explanation I think because of words like "transferred" imply
"moving" rather than "copying". So if we need to make clear that there is a new object
created (although connected to the same storage backing object):
context.attachCopy(object)
context.copy(object)
JPA and Hibernate use "merge()" for a similar operation don't they? I don't
know that I've tried it: what does localObject() do if the object already exists in the
target context? Will it overwrite any modified attributes?
Ari
[1] http://cayenne.apache.org/doc/moving-objects-between-contexts.html
On 5/09/11 11:33 AM, Andrus Adamchik wrote:
I am fine with it being a verb. The question is what verb. This action is not
"attach". It is something else. I tried to describe it in other messages in
this thread.
Andrus
On Sep 4, 2011, at 9:20 PM, Aristedes Maniatis wrote:
I also find localObject() a very confusing name. At the very least it should be
a verb, which is what Michael is getting at with his examples.
context.attach(object)
This would be accompanied by changes in the documentation terminology. You would "attach"
an object to a context, either automatically in the case of normal Cayenne object creation, or by
hand for POJOs (the Hibernate way), when copying from one context to another, etc. Ultimately the
same verb "attach" can be used to describe all those actions.
Ari
On 4/09/11 10:03 AM, Michael Gentry wrote:
Just the other day I started to try to explain this to a co-worker and
essentially told them "don't question it, just use it." That's
probably not the best answer.
I'm still not sure I like the method name localObject(). I think it
should be clear to the user that it takes an existing object (not a
new one) in one context and makes a copy of it to be also managed by a
different context. We need to keep localObject() around for a bit,
though, for backward compatibility.
Throwing some naming ideas out:
add(object)
manage(object)
register(object)
registerExistingObject(object) -- would be similar to registerNewObject(object)
In short, though, I agree this API should die. :-)
mrg
On Sat, Sep 3, 2011 at 5:16 PM, Andrus Adamchik<and...@objectstyle.org> wrote:
https://issues.apache.org/jira/browse/CAY-1611
I've got tired of doing:
Artist localArtist = (Artist) context.localArtist(artist.getObjectId(), null);
Aside from causing confusion about the second argument (should it be 'artist'?
no, it should be null), it is still plain ugly. Anyone sees any flaws with the
reasoning behind this Jira?
Andrus
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
