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 <andru..bjectstyle.org
> > 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
>>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Fri Jul 09 2010 - 15:19:06 UTC