I am not comfortable with adding a new public ObjectContext method
that will be hard to remove in the future. And I suspect it *will* be
removed/renamed. I know this is bad situation, as likely it won't get
implemented quickly (and most certainly not on 3.0 branch), and you
would want to use it right away... Maybe for now you'll create your
own utility or a DataContext subclass and we put the request in Jira?
Andrus
On Jul 9, 2010, at 6:01 PM, Michael Gentry wrote:
Our particular use-case is pulling objects into a child DC to edit and
isolate changes. Something like:
User localUser = childContext.localObject(user.getObjectId(), user);
Just seems like that can be simplified a bit for the developers.
Thanks,
mrg
On Fri, Jul 9, 2010 at 10:50 AM, Andrus Adamchik <[email protected]
> wrote:
Actually "localObject" is too loaded, performing a set of vaguely
related
distinct tasks... It has to be split into multiple methods (and
IIRC we
discussed it briefly some time ago). This particular variety is
closer to
"merge", vs. "localObject(id, null)" which is something like
"locate"...
Since this is rather visible public API and there are some caveats,
we need
to give it some more thought I think, identifying all the scenarios
before
creating appropriate methods.
Andrus
On Jul 9, 2010, at 5:36 PM, Michael Gentry wrote:
Would it make sense to add:
public Persistent localObject(Persistent source)
{
return localObject(source.getObjectId(), source)
}
to DataContext and friends? We are starting to use that a bit here
and it seems like it would be much simpler to me.
Thanks,
mrg
