cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@maniatis.org>
Subject Re: ObjectContext.localObject refactoring
Date Mon, 05 Sep 2011 06:33:44 GMT
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<andrus@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

Mime
View raw message