Grokbase Groups Cayenne dev July 2010
FAQ
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

Search Discussions

  • Andrus Adamchik at Jul 9, 2010 at 2:52 pm
    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
  • Michael Gentry at Jul 9, 2010 at 3:02 pm
    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 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
  • Andrus Adamchik at Jul 9, 2010 at 3:19 pm
    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
  • Michael Gentry at Jul 9, 2010 at 3:43 pm
    I was thinking we'd add a utility type method for now. I have no
    expectations of modifying 3.0 for this, but was thinking it might be
    good in the future to have something similar.

    Thanks,

    mrg

    On Fri, Jul 9, 2010 at 11:18 AM, Andrus Adamchik wrote:
    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
  • Andrus Adamchik at Jul 9, 2010 at 4:13 pm

    On Jul 9, 2010, at 6:41 PM, Michael Gentry wrote:

    I was thinking we'd add a utility type method for now. Cool.
    I have no
    expectations of modifying 3.0 for this, but was thinking it might be
    good in the future to have something similar.
    I am sure we will. I am stumbling over 'localObject' pretty often
    myself. It has to be done better.

    Andrus
  • Lachlan Deck at Jul 10, 2010 at 10:40 am

    On 10/07/2010, at 2:12 AM, Andrus Adamchik wrote:

    On Jul 9, 2010, at 6:41 PM, Michael Gentry wrote:

    I was thinking we'd add a utility type method for now. Cool.
    I have no
    expectations of modifying 3.0 for this, but was thinking it might be
    good in the future to have something similar.
    I am sure we will. I am stumbling over 'localObject' pretty often myself. It has to be done better.
    What about adding to the Persistent interface or its direct implementations: CayenneDataObject / PersistentObject? i.e.,
    public <P extends Persistent> localObject(P object);

    Failing that, add it to the default velocity templates... or people can add it to their own in the meantime.

    with regards,
    --

    Lachlan Deck
  • Michael Gentry at Jul 10, 2010 at 5:22 pm
    Well, if you want it in CayenneDataObject, you'd have to pass the
    target ObjectContext to the method, but that might be a pretty good
    place for it, too.

    mrg

    On Sat, Jul 10, 2010 at 6:40 AM, Lachlan Deck wrote:
    On 10/07/2010, at 2:12 AM, Andrus Adamchik wrote:

    On Jul 9, 2010, at 6:41 PM, Michael Gentry wrote:

    I was thinking we'd add a utility type method for now. Cool.
    I have no
    expectations of modifying 3.0 for this, but was thinking it might be
    good in the future to have something similar.
    I am sure we will. I am stumbling over 'localObject' pretty often myself. It has to be done better.
    What about adding to the Persistent interface or its direct implementations: CayenneDataObject / PersistentObject? i.e.,
    public <P extends Persistent> localObject(P object);

    Failing that, add it to the default velocity templates... or people can add it to their own in the meantime.

    with regards,
    --

    Lachlan Deck
  • Lachlan Deck at Jul 10, 2010 at 5:38 pm

    On 11/07/2010, at 3:21 AM, Michael Gentry wrote:

    Well, if you want it in CayenneDataObject, you'd have to pass the
    target ObjectContext to the method, but that might be a pretty good
    place for it, too.
    Silly me (for replying when tired), thanks. That was what I meant to say.
    public <T extends Persistent> T localObject(ObjectContext oc);
    i.e., ask the object for it rather than some utility class.

    with regards,
    --

    Lachlan Deck

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedJul 9, '10 at 2:38p
activeJul 10, '10 at 5:38p
posts9
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2023 Grokbase