On Sep 5, 2011, at 10:23 AM, Mike Kienenberger wrote:
> By the way, JPA.merge() is not close enough to localCopy() to use.
> Merge is more of a "update the object if it already exists rather than
> inserting a new one at commit". I think merge() would be a bad
> choice.
Yep, "merge" is differe
On Mon, Sep 5, 2011 at 2:33 AM, Aristedes Maniatis wrote:
> 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?
Unless something has changed, localObject(obj) returns the original
object obj
Maybe look at it the other way around?
dataObject.copyToContext(context)
mrg
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 opera
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
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 autom
The way I see it is that the concept itself is specific to Cayenne architecture
and requires some understanding. So if we call the method something else, by
itself it may not be sufficient to make it self-explanatory.
E.g. like I mentioned to me the best definition of this method is "mapping a
On Sat, Sep 3, 2011 at 9:44 PM, Andrus Adamchik wrote:
> Anyways, my suggestion would be to keep 'localObject' name for now. It is not
> ideal but good enough IMO.
Well, every co-worker I've ever told about localObject() found the
name confusing to them, which is why I was encouraging a new name
Just committed the new method, which is much more straightforward both from the
POV of the internal implementation and from the public API.
> 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 th
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 (no
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 f
11 matches
Mail list logo
