FAQ
I am in the middle of debugging a problem with nested ROP contexts
losing arc changes when committing to a parent context. Since I was
not involved in the ROP nested context work, I figured I'd post my
thoughts here before I start changing the code.

I noticed that per CAY-1119, there is a special subclass of
ChildDiffLoader called CayenneContextChildDiffLoader that calls
'propertyChanged' on the parent context after syncing a simple
property change. It seems like we need to do the same for
relationships as well, to record arc changes in the parent diff list.

Andrey, do you have any comments on that? I wonder if it was omitted
intentionally. I will open a Jira (I think we don't have one for
this), and add some tests with various relationships, but before I dig
any deeper figured I'll need a sanity check.

Thanks,
Andrus

Search Discussions

  • Andrey Razumovsky at Apr 4, 2009 at 5:31 am
    Hi Andrus,

    I'm afraid I don't remember if it was done intentionally. I only know that
    the code is different from normal contexts' diff processing (that's why I
    feel a large refactoring is needed). Feel free to change the code, of
    course. Alternatively, if you open a JIRA and post you JUnit there, I'll
    have a look.

    Andrey

    2009/4/3 Andrus Adamchik <andrus@objectstyle.org>
    I am in the middle of debugging a problem with nested ROP contexts losing
    arc changes when committing to a parent context. Since I was not involved in
    the ROP nested context work, I figured I'd post my thoughts here before I
    start changing the code.

    I noticed that per CAY-1119, there is a special subclass of ChildDiffLoader
    called CayenneContextChildDiffLoader that calls 'propertyChanged' on the
    parent context after syncing a simple property change. It seems like we need
    to do the same for relationships as well, to record arc changes in the
    parent diff list.

    Andrey, do you have any comments on that? I wonder if it was omitted
    intentionally. I will open a Jira (I think we don't have one for this), and
    add some tests with various relationships, but before I dig any deeper
    figured I'll need a sanity check.

    Thanks,
    Andrus
  • Andrus Adamchik at Apr 5, 2009 at 8:31 am
    Cool. I got a further along in my investigation. I will put the
    details in a Jira and work on fixing it.

    Andrus

    On Apr 4, 2009, at 8:31 AM, Andrey Razumovsky wrote:

    Hi Andrus,

    I'm afraid I don't remember if it was done intentionally. I only
    know that
    the code is different from normal contexts' diff processing (that's
    why I
    feel a large refactoring is needed). Feel free to change the code, of
    course. Alternatively, if you open a JIRA and post you JUnit there,
    I'll
    have a look.

    Andrey

    2009/4/3 Andrus Adamchik <andrus@objectstyle.org>
    I am in the middle of debugging a problem with nested ROP contexts
    losing
    arc changes when committing to a parent context. Since I was not
    involved in
    the ROP nested context work, I figured I'd post my thoughts here
    before I
    start changing the code.

    I noticed that per CAY-1119, there is a special subclass of
    ChildDiffLoader
    called CayenneContextChildDiffLoader that calls 'propertyChanged'
    on the
    parent context after syncing a simple property change. It seems
    like we need
    to do the same for relationships as well, to record arc changes in
    the
    parent diff list.

    Andrey, do you have any comments on that? I wonder if it was omitted
    intentionally. I will open a Jira (I think we don't have one for
    this), and
    add some tests with various relationships, but before I dig any
    deeper
    figured I'll need a sanity check.

    Thanks,
    Andrus
  • Andrus Adamchik at Apr 5, 2009 at 4:53 pm
    I committed the fix per CAY-1204. I encourage everybody using nested
    contexts in ROP to test it and report any problems.

    The essence of the fix was to set a thread-local state for whatever
    complex sequence of events is going on when a relationship is changed,
    determining how the context should handle graph changes. Per new non-
    public PropertyChangeProcessingStrategy enum, it is either of IGNORE,
    RECORD, RECORD_AND_PROCESS_REVERSE_ARCS (default). This allows to
    handle 3 common scenarios:

    "update from the DataChannel"
    "update from the child context"
    "update by the user"

    While this particular commit diverges client and server contexts
    further from each other, contrary to our stated goal of merging them
    together, I think the approach has a potential to become *the* way to
    do things throughout the stack. Ideally this will eliminate the method
    pairs of "doSomthing / doSomethingDirectly" from the API, which was a
    cornerstone of the graph management since Cayenne 1.0.

    Andrus

    On Apr 5, 2009, at 11:31 AM, Andrus Adamchik wrote:

    Cool. I got a further along in my investigation. I will put the
    details in a Jira and work on fixing it.

    Andrus

    On Apr 4, 2009, at 8:31 AM, Andrey Razumovsky wrote:

    Hi Andrus,

    I'm afraid I don't remember if it was done intentionally. I only
    know that
    the code is different from normal contexts' diff processing (that's
    why I
    feel a large refactoring is needed). Feel free to change the code, of
    course. Alternatively, if you open a JIRA and post you JUnit there,
    I'll
    have a look.

    Andrey

    2009/4/3 Andrus Adamchik <andrus@objectstyle.org>
    I am in the middle of debugging a problem with nested ROP contexts
    losing
    arc changes when committing to a parent context. Since I was not
    involved in
    the ROP nested context work, I figured I'd post my thoughts here
    before I
    start changing the code.

    I noticed that per CAY-1119, there is a special subclass of
    ChildDiffLoader
    called CayenneContextChildDiffLoader that calls 'propertyChanged'
    on the
    parent context after syncing a simple property change. It seems
    like we need
    to do the same for relationships as well, to record arc changes in
    the
    parent diff list.

    Andrey, do you have any comments on that? I wonder if it was omitted
    intentionally. I will open a Jira (I think we don't have one for
    this), and
    add some tests with various relationships, but before I dig any
    deeper
    figured I'll need a sanity check.

    Thanks,
    Andrus
  • Andrey Razumovsky at Nov 24, 2009 at 10:43 am
    Okay, I've run into same situation when trying to allow PO subclasses in DC,
    but now I don't see context setting reverse arcs at user's change. The
    problem is in difference between CC and DC property change processing. Sorry
    about being so detailed around the code, but I don't see how i can explain
    it otherwise.

    So, what DC does when setting an arc:
    1. Sets the value, which invokes context.propertyChanged()
    2. GraphAction just registers property change, nothing else
    3. Updates reverse arc
    4. GraphAction just registers property change, nothing else

    What CC does when setting an arc:
    1. Sets the value, which invokes context.propertyChanged()
    2. GraphAction just registers property change and...
    3. ...updates reverse arc
    4. with those ugly threadlocals in CCGraghAction ensures there are no
    infinite cycles

    I am sure the first approach is much better. I suggest that we:
    1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking Persistent
    instead of DO as an argument (actually I already did it locally)
    2. Make PersistentObjectHolder and other classes like that invoke
    context.propertChanged() should invoke those methods instead

    Ideally this will allow to:
    1. Leave only OCGraphAction and get rid of DCGraphAction and CCGraphAction
    with its ugly threadLocal
    2. Get rid of PropertyChangeProcessingStrategy
    3. Maybe, make client and server persistent holders more similiar

    2009/4/5 Andrus Adamchik <andrus@objectstyle.org>
    I committed the fix per CAY-1204. I encourage everybody using nested
    contexts in ROP to test it and report any problems.

    The essence of the fix was to set a thread-local state for whatever complex
    sequence of events is going on when a relationship is changed, determining
    how the context should handle graph changes. Per new non-public
    PropertyChangeProcessingStrategy enum, it is either of IGNORE, RECORD,
    RECORD_AND_PROCESS_REVERSE_ARCS (default). This allows to handle 3 common
    scenarios:

    "update from the DataChannel"
    "update from the child context"
    "update by the user"

    While this particular commit diverges client and server contexts further
    from each other, contrary to our stated goal of merging them together, I
    think the approach has a potential to become *the* way to do things
    throughout the stack. Ideally this will eliminate the method pairs of
    "doSomthing / doSomethingDirectly" from the API, which was a cornerstone of
    the graph management since Cayenne 1.0.

    Andrus



    On Apr 5, 2009, at 11:31 AM, Andrus Adamchik wrote:

    Cool. I got a further along in my investigation. I will put the details in
    a Jira and work on fixing it.

    Andrus


    On Apr 4, 2009, at 8:31 AM, Andrey Razumovsky wrote:

    Hi Andrus,
    I'm afraid I don't remember if it was done intentionally. I only know
    that
    the code is different from normal contexts' diff processing (that's why I
    feel a large refactoring is needed). Feel free to change the code, of
    course. Alternatively, if you open a JIRA and post you JUnit there, I'll
    have a look.

    Andrey

    2009/4/3 Andrus Adamchik <andrus@objectstyle.org>

    I am in the middle of debugging a problem with nested ROP contexts
    losing
    arc changes when committing to a parent context. Since I was not
    involved in
    the ROP nested context work, I figured I'd post my thoughts here before
    I
    start changing the code.

    I noticed that per CAY-1119, there is a special subclass of
    ChildDiffLoader
    called CayenneContextChildDiffLoader that calls 'propertyChanged' on the
    parent context after syncing a simple property change. It seems like we
    need
    to do the same for relationships as well, to record arc changes in the
    parent diff list.

    Andrey, do you have any comments on that? I wonder if it was omitted
    intentionally. I will open a Jira (I think we don't have one for this),
    and
    add some tests with various relationships, but before I dig any deeper
    figured I'll need a sanity check.

    Thanks,
    Andrus

    --
    Andrey
  • Andrus Adamchik at Nov 24, 2009 at 11:10 am
    I am ok with this as long as it doesn't break the ability for a to-
    many relationship collections to (un)set reverse relationships when
    regular collection add/remove methods are called.
    1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking
    Persistent
    instead of DO as an argument (actually I already did it locally)
    -1. I don't want to expose this API to the world, and also want to
    keep it pluggable (which is not possible with a static class).

    Andrus


    On Nov 24, 2009, at 12:42 PM, Andrey Razumovsky wrote:

    Okay, I've run into same situation when trying to allow PO
    subclasses in DC,
    but now I don't see context setting reverse arcs at user's change. The
    problem is in difference between CC and DC property change
    processing. Sorry
    about being so detailed around the code, but I don't see how i can
    explain
    it otherwise.

    So, what DC does when setting an arc:
    1. Sets the value, which invokes context.propertyChanged()
    2. GraphAction just registers property change, nothing else
    3. Updates reverse arc
    4. GraphAction just registers property change, nothing else

    What CC does when setting an arc:
    1. Sets the value, which invokes context.propertyChanged()
    2. GraphAction just registers property change and...
    3. ...updates reverse arc
    4. with those ugly threadlocals in CCGraghAction ensures there are no
    infinite cycles

    I am sure the first approach is much better. I suggest that we:
    1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking
    Persistent
    instead of DO as an argument (actually I already did it locally)
    2. Make PersistentObjectHolder and other classes like that invoke
    context.propertChanged() should invoke those methods instead

    Ideally this will allow to:
    1. Leave only OCGraphAction and get rid of DCGraphAction and
    CCGraphAction
    with its ugly threadLocal
    2. Get rid of PropertyChangeProcessingStrategy
    3. Maybe, make client and server persistent holders more similiar

    2009/4/5 Andrus Adamchik <andrus@objectstyle.org>
    I committed the fix per CAY-1204. I encourage everybody using nested
    contexts in ROP to test it and report any problems.

    The essence of the fix was to set a thread-local state for whatever
    complex
    sequence of events is going on when a relationship is changed,
    determining
    how the context should handle graph changes. Per new non-public
    PropertyChangeProcessingStrategy enum, it is either of IGNORE,
    RECORD,
    RECORD_AND_PROCESS_REVERSE_ARCS (default). This allows to handle 3
    common
    scenarios:

    "update from the DataChannel"
    "update from the child context"
    "update by the user"

    While this particular commit diverges client and server contexts
    further
    from each other, contrary to our stated goal of merging them
    together, I
    think the approach has a potential to become *the* way to do things
    throughout the stack. Ideally this will eliminate the method pairs of
    "doSomthing / doSomethingDirectly" from the API, which was a
    cornerstone of
    the graph management since Cayenne 1.0.

    Andrus



    On Apr 5, 2009, at 11:31 AM, Andrus Adamchik wrote:

    Cool. I got a further along in my investigation. I will put the
    details in
    a Jira and work on fixing it.

    Andrus


    On Apr 4, 2009, at 8:31 AM, Andrey Razumovsky wrote:

    Hi Andrus,
    I'm afraid I don't remember if it was done intentionally. I only
    know
    that
    the code is different from normal contexts' diff processing
    (that's why I
    feel a large refactoring is needed). Feel free to change the
    code, of
    course. Alternatively, if you open a JIRA and post you JUnit
    there, I'll
    have a look.

    Andrey

    2009/4/3 Andrus Adamchik <andrus@objectstyle.org>

    I am in the middle of debugging a problem with nested ROP contexts
    losing
    arc changes when committing to a parent context. Since I was not
    involved in
    the ROP nested context work, I figured I'd post my thoughts here
    before
    I
    start changing the code.

    I noticed that per CAY-1119, there is a special subclass of
    ChildDiffLoader
    called CayenneContextChildDiffLoader that calls
    'propertyChanged' on the
    parent context after syncing a simple property change. It seems
    like we
    need
    to do the same for relationships as well, to record arc changes
    in the
    parent diff list.

    Andrey, do you have any comments on that? I wonder if it was
    omitted
    intentionally. I will open a Jira (I think we don't have one for
    this),
    and
    add some tests with various relationships, but before I dig any
    deeper
    figured I'll need a sanity check.

    Thanks,
    Andrus

    --
    Andrey
  • Andrey Razumovsky at Nov 24, 2009 at 11:21 am
    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    I am ok with this as long as it doesn't break the ability for a to-many
    relationship collections to (un)set reverse relationships when regular
    collection add/remove methods are called.
    Sure

    1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking Persistent
    instead of DO as an argument (actually I already did it locally)
    -1. I don't want to expose this API to the world, and also want to keep it
    pluggable (which is not possible with a static class).
    We should sort out *what* should be pluggable here. Property injection in
    ever pluggable, and methods DataObject.setToOneTarget(...) (and I want it to
    be DataObjectUtils.setToOneTarget(Persistent, ...)) is just a helper method
    that calls those pluggable mechanisms. The need of setting reverse
    relationships is a paramdigm and has no need to become pluggable. Have you
    ever overridden DataObject.setToOneTarget()?
    Anyways, at the minimum, as i mentioned somewhere before, i'd like to see
    something helper like DataObjectUtils.readProperty(Persistent, String) for
    simple and unified access to DO's properties any any tier

    Andrus




    On Nov 24, 2009, at 12:42 PM, Andrey Razumovsky wrote:

    Okay, I've run into same situation when trying to allow PO subclasses in
    DC,
    but now I don't see context setting reverse arcs at user's change. The
    problem is in difference between CC and DC property change processing.
    Sorry
    about being so detailed around the code, but I don't see how i can explain
    it otherwise.

    So, what DC does when setting an arc:
    1. Sets the value, which invokes context.propertyChanged()
    2. GraphAction just registers property change, nothing else
    3. Updates reverse arc
    4. GraphAction just registers property change, nothing else

    What CC does when setting an arc:
    1. Sets the value, which invokes context.propertyChanged()
    2. GraphAction just registers property change and...
    3. ...updates reverse arc
    4. with those ugly threadlocals in CCGraghAction ensures there are no
    infinite cycles

    I am sure the first approach is much better. I suggest that we:
    1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking Persistent
    instead of DO as an argument (actually I already did it locally)
    2. Make PersistentObjectHolder and other classes like that invoke
    context.propertChanged() should invoke those methods instead

    Ideally this will allow to:
    1. Leave only OCGraphAction and get rid of DCGraphAction and CCGraphAction
    with its ugly threadLocal
    2. Get rid of PropertyChangeProcessingStrategy
    3. Maybe, make client and server persistent holders more similiar

    2009/4/5 Andrus Adamchik <andrus@objectstyle.org>

    I committed the fix per CAY-1204. I encourage everybody using nested
    contexts in ROP to test it and report any problems.

    The essence of the fix was to set a thread-local state for whatever
    complex
    sequence of events is going on when a relationship is changed,
    determining
    how the context should handle graph changes. Per new non-public
    PropertyChangeProcessingStrategy enum, it is either of IGNORE, RECORD,
    RECORD_AND_PROCESS_REVERSE_ARCS (default). This allows to handle 3 common
    scenarios:

    "update from the DataChannel"
    "update from the child context"
    "update by the user"

    While this particular commit diverges client and server contexts further
    from each other, contrary to our stated goal of merging them together, I
    think the approach has a potential to become *the* way to do things
    throughout the stack. Ideally this will eliminate the method pairs of
    "doSomthing / doSomethingDirectly" from the API, which was a cornerstone
    of
    the graph management since Cayenne 1.0.

    Andrus



    On Apr 5, 2009, at 11:31 AM, Andrus Adamchik wrote:

    Cool. I got a further along in my investigation. I will put the details
    in
    a Jira and work on fixing it.

    Andrus


    On Apr 4, 2009, at 8:31 AM, Andrey Razumovsky wrote:

    Hi Andrus,
    I'm afraid I don't remember if it was done intentionally. I only know
    that
    the code is different from normal contexts' diff processing (that's why
    I
    feel a large refactoring is needed). Feel free to change the code, of
    course. Alternatively, if you open a JIRA and post you JUnit there,
    I'll
    have a look.

    Andrey

    2009/4/3 Andrus Adamchik <andrus@objectstyle.org>

    I am in the middle of debugging a problem with nested ROP contexts
    losing
    arc changes when committing to a parent context. Since I was not
    involved in
    the ROP nested context work, I figured I'd post my thoughts here
    before
    I
    start changing the code.

    I noticed that per CAY-1119, there is a special subclass of
    ChildDiffLoader
    called CayenneContextChildDiffLoader that calls 'propertyChanged' on
    the
    parent context after syncing a simple property change. It seems like
    we
    need
    to do the same for relationships as well, to record arc changes in the
    parent diff list.

    Andrey, do you have any comments on that? I wonder if it was omitted
    intentionally. I will open a Jira (I think we don't have one for
    this),
    and
    add some tests with various relationships, but before I dig any deeper
    figured I'll need a sanity check.

    Thanks,
    Andrus

    --
    Andrey

    --
    Andrey
  • Andrus Adamchik at Nov 24, 2009 at 11:29 am

    On Nov 24, 2009, at 1:20 PM, Andrey Razumovsky wrote:

    Have you
    ever overridden DataObject.setToOneTarget()?
    I did not, but I defined 3 different types of objects (ROP, POJO, JPA)
    that don't use this approach for setting reverse relationship. So
    that's what I mean by pluggable :-)
    Anyways, at the minimum, as i mentioned somewhere before, i'd like
    to see
    something helper like DataObjectUtils.readProperty(Persistent,
    String) for
    simple and unified access to DO's properties any any tier
    Property p = ClassDescriptor.getProperty(String);
    p.readProperty(Object);
    p.readPropertyDirectly(Object);

    Andrus
  • Andrey Razumovsky at Nov 24, 2009 at 11:37 am
    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    I did not, but I defined 3 different types of objects (ROP, POJO, JPA) that
    don't use this approach for setting reverse relationship. So that's what I
    mean by pluggable :-)
    And now I want at least ROP-like classes do use this approach as well (i
    mean what is contained inside "setToOneTarget" method). I just want to
    minimize duplicating the code. Alternatively, same code will be added to the
    places where we process those "different types".

    Property p = ClassDescriptor.getProperty(String);
    p.readProperty(Object);
    p.readPropertyDirectly(Object);
    ...and more lines to get ClassDescriptor:

    ClassDescriptor cd = object.getObjectContext().

    getEntityResolver().getClassDescriptor(object.getObjectId().getEntityName());
    Too hard for user who does not know Cayenne internals I think
  • Robert Zeigler at Nov 24, 2009 at 11:42 am

    On Nov 24, 2009, at 11/245:37 AM , Andrey Razumovsky wrote:

    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    I did not, but I defined 3 different types of objects (ROP, POJO,
    JPA) that
    don't use this approach for setting reverse relationship. So that's
    what I
    mean by pluggable :-)
    And now I want at least ROP-like classes do use this approach as
    well (i
    mean what is contained inside "setToOneTarget" method). I just want to
    minimize duplicating the code. Alternatively, same code will be
    added to the
    places where we process those "different types".

    Property p = ClassDescriptor.getProperty(String);
    p.readProperty(Object);
    p.readPropertyDirectly(Object);
    ...and more lines to get ClassDescriptor:

    ClassDescriptor cd = object.getObjectContext().

    getEntityResolver
    ().getClassDescriptor(object.getObjectId().getEntityName());
    Too hard for user who does not know Cayenne internals I think
    I'll second that. I ran into a very similar use case yesterday in a
    hibernate project... I was wanting to get at hibernate's version of
    ClassDescription, and it took me forever to track down the right way
    to do it; once I knew how, it was simple enough, and just a few lines
    of code, but I fear the above would cause a new Cayenne user the same
    level of frustration I experienced yesterday with Hibernate. ;)

    Robert
  • Andrus Adamchik at Nov 24, 2009 at 11:53 am
    [As suggested in the parent thread, forking a new thread]
    On Nov 24, 2009, at 1:41 PM, Robert Zeigler wrote:

    I'll second that. I ran into a very similar use case yesterday in a
    hibernate project... I was wanting to get at hibernate's version of
    ClassDescription, and it took me forever to track down the right way
    to do it; once I knew how, it was simple enough, and just a few
    lines of code, but I fear the above would cause a new Cayenne user
    the same level of frustration I experienced yesterday with
    Hibernate. ;)
    I wouldn't mind if we add methods for ClassDescriptor lookups to the
    DataObjectUtils. BTW PersistentObject defines 'getObjEntity' method.
    I'd say we replace that with 'getClassDescriptor' and move it to a
    utility class.

    While we are at it, maybe rename DataObjectUtils to something more
    appropriate and shorter. CayenneUtil? Cayenne? ("Util" is already
    taken, and I'd rather it identify the origin of the framework).

    I sort of like calling it just "Cayenne" (for the same reasons of user
    simplicity), but then it implies this is a central class in the
    framework, and has more than just lookup-by-pk or give-me-metadata
    methods.

    Andrus
  • Robert Zeigler at Nov 24, 2009 at 11:59 am
    CayUtils? I'm good with Cayenne, too.

    Robert
    On Nov 24, 2009, at 11/245:53 AM , Andrus Adamchik wrote:

    [As suggested in the parent thread, forking a new thread]
    On Nov 24, 2009, at 1:41 PM, Robert Zeigler wrote:

    I'll second that. I ran into a very similar use case yesterday in a
    hibernate project... I was wanting to get at hibernate's version of
    ClassDescription, and it took me forever to track down the right
    way to do it; once I knew how, it was simple enough, and just a few
    lines of code, but I fear the above would cause a new Cayenne user
    the same level of frustration I experienced yesterday with
    Hibernate. ;)
    I wouldn't mind if we add methods for ClassDescriptor lookups to the
    DataObjectUtils. BTW PersistentObject defines 'getObjEntity' method.
    I'd say we replace that with 'getClassDescriptor' and move it to a
    utility class.

    While we are at it, maybe rename DataObjectUtils to something more
    appropriate and shorter. CayenneUtil? Cayenne? ("Util" is already
    taken, and I'd rather it identify the origin of the framework).

    I sort of like calling it just "Cayenne" (for the same reasons of
    user simplicity), but then it implies this is a central class in the
    framework, and has more than just lookup-by-pk or give-me-metadata
    methods.

    Andrus
  • Andrey Razumovsky at Nov 24, 2009 at 12:14 pm
    Cayenne or maybe PersistentUtils - because it will work with all types of
    classes (or at least those that implement Persistent).
  • Lachlan Deck at Nov 24, 2009 at 11:02 pm

    On 24/11/2009, at 11:13 PM, Andrey Razumovsky wrote:

    or maybe PersistentUtils
    +1 makes the most sense (to me at least) given it reflects the flavour of the interface to which these objects belong whether server-side or not.
    - because it will work with all types of
    classes (or at least those that implement Persistent).
    with regards,
    --

    Lachlan Deck
  • Michael Gentry at Nov 24, 2009 at 2:35 pm
    I tend to not like abbreviations for the most part (a little peeve of
    mine -- I fall into the "software is meant to be read, not written"
    camp), so I'd vote for something more like "Cayenne" in the current
    org.apache.cayenne.util package. Simple, direct, and to the point.

    mrg

    On Tue, Nov 24, 2009 at 6:53 AM, Andrus Adamchik wrote:
    [As suggested in the parent thread, forking a new thread]
    On Nov 24, 2009, at 1:41 PM, Robert Zeigler wrote:

    I'll second that. I ran into a very similar use case yesterday in a
    hibernate project... I was wanting to get at hibernate's version of
    ClassDescription, and it took me forever to track down the right way to do
    it; once I knew how, it was simple enough, and just a few lines of code, but
    I fear the above would cause a new Cayenne user the same level of
    frustration I experienced yesterday with Hibernate. ;)
    I wouldn't mind if we add methods for ClassDescriptor lookups to the
    DataObjectUtils. BTW PersistentObject defines 'getObjEntity' method. I'd say
    we replace that with 'getClassDescriptor' and move it to a utility class.

    While we are at it, maybe rename DataObjectUtils to something more
    appropriate and shorter. CayenneUtil? Cayenne? ("Util" is already taken, and
    I'd rather it identify the origin of the framework).

    I sort of like calling it just "Cayenne" (for the same reasons of user
    simplicity), but then it implies this is a central class in the framework,
    and has more than just lookup-by-pk or give-me-metadata methods.

    Andrus

  • Andrus Adamchik at Nov 24, 2009 at 11:43 am
    So here is a high-level question - do you think we can use
    ClassDescriptor/Property abstraction *internally* to build a unified
    ObjectContext implementation for any kind of objects? This was the
    goal of the reflect package anyways.
    getEntityResolver
    ().getClassDescriptor(object.getObjectId().getEntityName());
    Too hard for user who does not know Cayenne internals I think
    Fine, but we are talking about two different things here - how to
    build a single context for DO and PO and how to build user interface
    for some specific convenience tasks. Let's discuss those 2 things
    separately.

    Andrus

    On Nov 24, 2009, at 1:37 PM, Andrey Razumovsky wrote:

    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    I did not, but I defined 3 different types of objects (ROP, POJO,
    JPA) that
    don't use this approach for setting reverse relationship. So that's
    what I
    mean by pluggable :-)
    And now I want at least ROP-like classes do use this approach as
    well (i
    mean what is contained inside "setToOneTarget" method). I just want to
    minimize duplicating the code. Alternatively, same code will be
    added to the
    places where we process those "different types".

    Property p = ClassDescriptor.getProperty(String);
    p.readProperty(Object);
    p.readPropertyDirectly(Object);
    ...and more lines to get ClassDescriptor:

    ClassDescriptor cd = object.getObjectContext().

    getEntityResolver
    ().getClassDescriptor(object.getObjectId().getEntityName());
    Too hard for user who does not know Cayenne internals I think
  • Andrey Razumovsky at Nov 24, 2009 at 12:10 pm
    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    So here is a high-level question - do you think we can use
    ClassDescriptor/Property abstraction *internally* to build a unified
    ObjectContext implementation for any kind of objects? This was the goal of
    the reflect package anyways.
    I think yes. In future :) Because currently, say, DataObject defines some
    processing that cannot be avaliable in other types due to "skin" nature of
    other objects. Other types (e.g. ROP) don't use these processings, so there
    were created quite a lot of classes for different handling of objects. I see
    that code to be moved to utility class..

    The major high-level question is - should be process *graphs* of all types
    of objects somewhat identically. I think yes. I think that ThreadLocals,
    ProperyChangeProcessingStrategies and many other things were created due to
    lack of methods of "core" processing of graphs and objects.
    If this is correct in essence, we unify different contexts. All other is a
    matter of refactoring.

    Maybe we're just talking about different things - let me just do a minor
    step in my direction and upload what I have so that we could talk around the
    code.
  • Andrey Razumovsky at Nov 24, 2009 at 2:31 pm
    Now returning to my main goal - it is to allow PersistentObject subclasses
    work correctly on server and cannot be done without changing
    PersistentObjectHolder's event procession.
    The only reason that we have those PropertyChangeProcessingStrategy and many
    threadLocals all around is that PersistentObject-collections must notify
    context unlike ToMany-collections. So, if we are setting reverse arc via
    add() or remove() we get infinite loops an other nasty things.
    We already have readProperty/readPropertyDirectly pair for simple
    properties, where readPropertyDirectly is "silent". My question is - why
    can't we have "silent" addTargetDirectly and removeTargetDirectly for
    to-many properties? This will allow as to manage event cycles. I think this
    will eliminate threadlocals and make Cayenne code simpler and safer
  • Andrey Razumovsky at Nov 24, 2009 at 2:33 pm
    For POJOs and DO's it can work same as non-silent one, and for ROPs it will
    differ

    2009/11/24 Andrey Razumovsky <razumovsky.andrey@gmail.com>
    Now returning to my main goal - it is to allow PersistentObject subclasses
    work correctly on server and cannot be done without changing
    PersistentObjectHolder's event procession.
    The only reason that we have those PropertyChangeProcessingStrategy and
    many threadLocals all around is that PersistentObject-collections must
    notify context unlike ToMany-collections. So, if we are setting reverse arc
    via add() or remove() we get infinite loops an other nasty things.
    We already have readProperty/readPropertyDirectly pair for simple
    properties, where readPropertyDirectly is "silent". My question is - why
    can't we have "silent" addTargetDirectly and removeTargetDirectly for
    to-many properties? This will allow as to manage event cycles. I think this
    will eliminate threadlocals and make Cayenne code simpler and safer


    --
    Andrey
  • Andrus Adamchik at Nov 24, 2009 at 2:54 pm

    My question is - why
    can't we have "silent" addTargetDirectly and removeTargetDirectly for
    to-many properties? This will allow as to manage event cycles.

    I guess we can. This should replace "addReverse" parameter in the
    appropriate method. Talking from memory here, I may not remember all
    the stumbling blocks there (or even the full cycle of property
    setting). So if you can make it work, excellent.

    Also to make sure we are talking about the same thing... The question
    is who will be the owner of these methods - Object itself (as in DO),
    a to-many collection, or to-many property descriptor? I am thinking
    "property descriptor" (and possibly an underlying collection).
    For POJOs and DO's it can work same as non-silent one, and for ROPs
    it will
    differ
    "directly" means it won't trip a DB operation. So ideally it should
    work the same for all..



    So ... another attempt at abstract analysis (or an attempt at
    unwinding my memory...) IIRC the main difference between DO and PO is
    fault handling - we can store a Fault instance in a map, but not in a
    typed ivar. So PO's have no concepts of faults at all, and the
    lifecycle is different. DO approach is more lazy (it won't try to
    create even a placeholder collection until the property is accessed),
    and I prefer it to PO's. Wonder if when we reconcile that somehow, the
    rest will fall into place on its own??

    (E.g. for PO's, we generate extra boolean "fault" properties for each
    relationship, that are checked on every property access?)

    Andrus




    On Nov 24, 2009, at 4:33 PM, Andrey Razumovsky wrote:

    For POJOs and DO's it can work same as non-silent one, and for ROPs
    it will
    differ

    2009/11/24 Andrey Razumovsky <razumovsky.andrey@gmail.com>
    Now returning to my main goal - it is to allow PersistentObject
    subclasses
    work correctly on server and cannot be done without changing
    PersistentObjectHolder's event procession.
    The only reason that we have those PropertyChangeProcessingStrategy
    and
    many threadLocals all around is that PersistentObject-collections
    must
    notify context unlike ToMany-collections. So, if we are setting
    reverse arc
    via add() or remove() we get infinite loops an other nasty things.
    We already have readProperty/readPropertyDirectly pair for simple
    properties, where readPropertyDirectly is "silent". My question is
    - why
    can't we have "silent" addTargetDirectly and removeTargetDirectly for
    to-many properties? This will allow as to manage event cycles. I
    think this
    will eliminate threadlocals and make Cayenne code simpler and safer


    --
    Andrey
  • Andrey Razumovsky at Nov 24, 2009 at 3:15 pm
    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    My question is - why
    can't we have "silent" addTargetDirectly and removeTargetDirectly for
    to-many properties? This will allow as to manage event cycles.
    I guess we can. This should replace "addReverse" parameter in the
    appropriate method. Talking from memory here, I may not remember all the
    stumbling blocks there (or even the full cycle of property setting). So if
    you can make it work, excellent.

    Also to make sure we are talking about the same thing... The question is
    who will be the owner of these methods - Object itself (as in DO), a to-many
    collection, or to-many property descriptor? I am thinking "property
    descriptor" (and possibly an underlying collection).
    to-many collection and to-many property descriptor I guess.

    For POJOs and DO's it can work same as non-silent one, and for ROPs it
    will
    differ
    "directly" means it won't trip a DB operation. So ideally it should work
    the same for all..
    "Directly" means it puts value directly to underlying collection (if any).
    I'll see if there is solution for all.

    So ... another attempt at abstract analysis (or an attempt at unwinding my
    memory...) IIRC the main difference between DO and PO is fault handling - we
    can store a Fault instance in a map, but not in a typed ivar. So PO's have
    no concepts of faults at all, and the lifecycle is different. DO approach is
    more lazy (it won't try to create even a placeholder collection until the
    property is accessed), and I prefer it to PO's. Wonder if when we reconcile
    that somehow, the rest will fall into place on its own??

    (E.g. for PO's, we generate extra boolean "fault" properties for each
    relationship, that are checked on every property access?)
    Nice idea, need to think about it. But anyways, this is separate task
  • Andrus Adamchik at Nov 24, 2009 at 3:54 pm

    On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:



    So ... another attempt at abstract analysis (or an attempt at
    unwinding my
    memory...) IIRC the main difference between DO and PO is fault
    handling - we
    can store a Fault instance in a map, but not in a typed ivar. So
    PO's have
    no concepts of faults at all, and the lifecycle is different. DO
    approach is
    more lazy (it won't try to create even a placeholder collection
    until the
    property is accessed), and I prefer it to PO's. Wonder if when we
    reconcile
    that somehow, the rest will fall into place on its own??

    (E.g. for PO's, we generate extra boolean "fault" properties for each
    relationship, that are checked on every property access?)
    Nice idea, need to think about it. But anyways, this is separate task
    May or may not be a separate task. But definitely bigger in scope.

    Andrus
  • Andrey Razumovsky at Nov 24, 2009 at 7:29 pm
    Actually, I don't understand :) PO arc properties are all faults (classes
    PersistentObject*)

    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:

    So ... another attempt at abstract analysis (or an attempt at unwinding
    my
    memory...) IIRC the main difference between DO and PO is fault handling -
    we
    can store a Fault instance in a map, but not in a typed ivar. So PO's
    have
    no concepts of faults at all, and the lifecycle is different. DO approach
    is
    more lazy (it won't try to create even a placeholder collection until the
    property is accessed), and I prefer it to PO's. Wonder if when we
    reconcile
    that somehow, the rest will fall into place on its own??

    (E.g. for PO's, we generate extra boolean "fault" properties for each
    relationship, that are checked on every property access?)
    Nice idea, need to think about it. But anyways, this is separate task
    May or may not be a separate task. But definitely bigger in scope.

    Andrus

    --
    Andrey
  • Andrus Adamchik at Nov 24, 2009 at 7:47 pm
    True, but they are still user facing collections (or more generally
    valueholders, as this also works for to-one), that get inflated
    internally as needed. DO faults are singletons of this type:

    http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html

    So PO lazy relationship resolving goes like this:

    1. on select, init lazy property with a "hollow" ValueHolder
    2. on ValueHolder value access, inflate ValueHolder with the DB data

    For DO it has an extra step:

    1. on select, init lazy property with a singleton Fault of a type
    corresponding to the relationship semantics
    2. on property access, *replace* Fault with either a hollow
    collection or a target DO (which can be hollow or resolved from cache)
    3. on collection or hollow DO value access, inflate them.

    The difference may be subtle, but still essential. First, in DO case
    there's no to-one ValueHolder. Target object is attached directly.
    Also the user never sees the Fault object itself, so we can replace it
    with another object when needed. Among other things this allows a
    major memory optimization, as Fault instances are singletons shared by
    all DOs.

    So all in all, DO design seems more sound (and quite possibly that
    whatever memory we save on using ivars in PO, is getting lost to extra
    and more eager ValueHolders).

    Andrus

    On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote:

    Actually, I don't understand :) PO arc properties are all faults
    (classes
    PersistentObject*)

    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:

    So ... another attempt at abstract analysis (or an attempt at
    unwinding
    my
    memory...) IIRC the main difference between DO and PO is fault
    handling -
    we
    can store a Fault instance in a map, but not in a typed ivar. So
    PO's
    have
    no concepts of faults at all, and the lifecycle is different. DO
    approach
    is
    more lazy (it won't try to create even a placeholder collection
    until the
    property is accessed), and I prefer it to PO's. Wonder if when we
    reconcile
    that somehow, the rest will fall into place on its own??

    (E.g. for PO's, we generate extra boolean "fault" properties for
    each
    relationship, that are checked on every property access?)
    Nice idea, need to think about it. But anyways, this is separate
    task
    May or may not be a separate task. But definitely bigger in scope.

    Andrus

    --
    Andrey
  • Andrey Razumovsky at Nov 24, 2009 at 8:36 pm
    Just committed changes in ROP event processing. In a nutshell, changes are:
    -removed all ThreadLocals and PropertyChangeProcessingStrategy
    -removed CCGraphAction & DCGraphAction to the glory of OCGraphAction
    -added to methods to ToManyProperty
    -added util.Cayenne class with some internal and external methods
    -added new "Light Server Superclass" template. It allows to generate
    ROP-like server classes (in fact, it allows same classes for server &
    client). Classes like that can be generated through "Advanced" menu.
    Currently it is adviced to set superclass
    "org.apache.cayenne.PersistentObject" (nothing else tested)
    -added little test (LightServerTest) for testing ROP-like server classes.
    very simple, still need to figure out how to create test stacks for server &
    client at once

    my war against two branches of classes continues :)
  • Andrus Adamchik at Nov 25, 2009 at 8:35 am

    my war against two branches of classes continues :)
    Great job :-)
    -added little test (LightServerTest) for testing ROP-like server
    classes.
    very simple, still need to figure out how to create test stacks for
    server &
    client at once

    As a side note, I was thinking of an overhaul of the test framework
    for some time. Tests under cayenne-jdk1.5-unpublished are rather hard
    to manage. E.g. group by DB type (some tests are not supported on some
    DB's), create data assemblies, etc. There's also lots of obsolete
    stuff (like Spring-based SQL queries).

    Olga did research on the background of JUnit4 and TestNG as the
    possible alternatives. This is a topic for separate thread, I was just
    holding it off intentionally, as we had a bunch of other active
    discussions and it's been a bit overwhelming to follow all of them.
    -added util.Cayenne class with some internal and external methods
    Excellent! May I nitpick a bit ? :-)

    Can we split non-public methods into a non-public class under the util
    package (maybe even the existing org.apache.cayenne.util.Util), and
    move Cayenne to org.apache.cayenne package?

    Also since DataObjectUtils deprecation is a pretty serious frontend
    change, can we open a Jira for tracking purposes (and close it right
    after putting it in RELEASE-NOTES).

    Andrus

    On Nov 24, 2009, at 10:36 PM, Andrey Razumovsky wrote:

    Just committed changes in ROP event processing. In a nutshell,
    changes are:
    -removed all ThreadLocals and PropertyChangeProcessingStrategy
    -removed CCGraphAction & DCGraphAction to the glory of OCGraphAction
    -added to methods to ToManyProperty
    -added util.Cayenne class with some internal and external methods
    -added new "Light Server Superclass" template. It allows to generate
    ROP-like server classes (in fact, it allows same classes for server &
    client). Classes like that can be generated through "Advanced" menu.
    Currently it is adviced to set superclass
    "org.apache.cayenne.PersistentObject" (nothing else tested)
    -added little test (LightServerTest) for testing ROP-like server
    classes.
    very simple, still need to figure out how to create test stacks for
    server &
    client at once

    my war against two branches of classes continues :)
  • Andrus Adamchik at Nov 30, 2009 at 10:09 am
    Another possible "lightweight" design that would allow to reconcile
    DO's and PO's is to use Object[] instead of either HashMap or ivars to
    store values, with indexes in array corresponding to ObjAttribute
    names sorted in alphabetic order. Will probably have its own quirks I
    guess (e.g. how do we define the array size for a generic object that
    can be mapped to different entities), however it has some serious
    benefits:

    * memory use very close to ivars
    * access speed very close to ivars
    * can be used with Faults
    * can be used with generic objects

    Andrus

    On Nov 24, 2009, at 9:47 PM, Andrus Adamchik wrote:

    True, but they are still user facing collections (or more generally
    valueholders, as this also works for to-one), that get inflated
    internally as needed. DO faults are singletons of this type:

    http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html

    So PO lazy relationship resolving goes like this:

    1. on select, init lazy property with a "hollow" ValueHolder
    2. on ValueHolder value access, inflate ValueHolder with the DB data

    For DO it has an extra step:

    1. on select, init lazy property with a singleton Fault of a type
    corresponding to the relationship semantics
    2. on property access, *replace* Fault with either a hollow
    collection or a target DO (which can be hollow or resolved from cache)
    3. on collection or hollow DO value access, inflate them.

    The difference may be subtle, but still essential. First, in DO case
    there's no to-one ValueHolder. Target object is attached directly.
    Also the user never sees the Fault object itself, so we can replace
    it with another object when needed. Among other things this allows a
    major memory optimization, as Fault instances are singletons shared
    by all DOs.

    So all in all, DO design seems more sound (and quite possibly that
    whatever memory we save on using ivars in PO, is getting lost to
    extra and more eager ValueHolders).

    Andrus

    On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote:

    Actually, I don't understand :) PO arc properties are all faults
    (classes
    PersistentObject*)

    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:

    So ... another attempt at abstract analysis (or an attempt at
    unwinding
    my
    memory...) IIRC the main difference between DO and PO is fault
    handling -
    we
    can store a Fault instance in a map, but not in a typed ivar. So
    PO's
    have
    no concepts of faults at all, and the lifecycle is different. DO
    approach
    is
    more lazy (it won't try to create even a placeholder collection
    until the
    property is accessed), and I prefer it to PO's. Wonder if when we
    reconcile
    that somehow, the rest will fall into place on its own??

    (E.g. for PO's, we generate extra boolean "fault" properties for
    each
    relationship, that are checked on every property access?)
    Nice idea, need to think about it. But anyways, this is separate
    task
    May or may not be a separate task. But definitely bigger in scope.

    Andrus

    --
    Andrey
  • Tore Halset at Nov 30, 2009 at 10:23 am
    Hello.

    Would it be possible to have attributes within an entity as enum and
    then use EnumMap? It uses an array for storage, so it does not need
    the buly Map.Entry objects used in a normal HashMap.

    - Tore.
    On Nov 30, 2009, at 11:09 , Andrus Adamchik wrote:

    Another possible "lightweight" design that would allow to reconcile
    DO's and PO's is to use Object[] instead of either HashMap or ivars
    to store values, with indexes in array corresponding to ObjAttribute
    names sorted in alphabetic order. Will probably have its own quirks
    I guess (e.g. how do we define the array size for a generic object
    that can be mapped to different entities), however it has some
    serious benefits:

    * memory use very close to ivars
    * access speed very close to ivars
    * can be used with Faults
    * can be used with generic objects

    Andrus

    On Nov 24, 2009, at 9:47 PM, Andrus Adamchik wrote:

    True, but they are still user facing collections (or more generally
    valueholders, as this also works for to-one), that get inflated
    internally as needed. DO faults are singletons of this type:

    http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html

    So PO lazy relationship resolving goes like this:

    1. on select, init lazy property with a "hollow" ValueHolder
    2. on ValueHolder value access, inflate ValueHolder with the DB data

    For DO it has an extra step:

    1. on select, init lazy property with a singleton Fault of a type
    corresponding to the relationship semantics
    2. on property access, *replace* Fault with either a hollow
    collection or a target DO (which can be hollow or resolved from
    cache)
    3. on collection or hollow DO value access, inflate them.

    The difference may be subtle, but still essential. First, in DO
    case there's no to-one ValueHolder. Target object is attached
    directly. Also the user never sees the Fault object itself, so we
    can replace it with another object when needed. Among other things
    this allows a major memory optimization, as Fault instances are
    singletons shared by all DOs.

    So all in all, DO design seems more sound (and quite possibly that
    whatever memory we save on using ivars in PO, is getting lost to
    extra and more eager ValueHolders).

    Andrus

    On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote:

    Actually, I don't understand :) PO arc properties are all faults
    (classes
    PersistentObject*)

    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:

    So ... another attempt at abstract analysis (or an attempt at
    unwinding
    my
    memory...) IIRC the main difference between DO and PO is fault
    handling -
    we
    can store a Fault instance in a map, but not in a typed ivar.
    So PO's
    have
    no concepts of faults at all, and the lifecycle is different.
    DO approach
    is
    more lazy (it won't try to create even a placeholder collection
    until the
    property is accessed), and I prefer it to PO's. Wonder if when we
    reconcile
    that somehow, the rest will fall into place on its own??

    (E.g. for PO's, we generate extra boolean "fault" properties
    for each
    relationship, that are checked on every property access?)
    Nice idea, need to think about it. But anyways, this is separate
    task
    May or may not be a separate task. But definitely bigger in scope.

    Andrus

    --
    Andrey
  • Andrus Adamchik at Nov 30, 2009 at 11:07 am
    Exactly, I also thought of generating an internal enum of attribute
    keys. From there we can either use an EnumMap wrapper of object[] or
    just the array.

    Andrus

    On Nov 30, 2009, at 12:23 PM, Tore Halset wrote:

    Hello.

    Would it be possible to have attributes within an entity as enum and
    then use EnumMap? It uses an array for storage, so it does not need
    the buly Map.Entry objects used in a normal HashMap.

    - Tore.
    On Nov 30, 2009, at 11:09 , Andrus Adamchik wrote:

    Another possible "lightweight" design that would allow to reconcile
    DO's and PO's is to use Object[] instead of either HashMap or ivars
    to store values, with indexes in array corresponding to
    ObjAttribute names sorted in alphabetic order. Will probably have
    its own quirks I guess (e.g. how do we define the array size for a
    generic object that can be mapped to different entities), however
    it has some serious benefits:

    * memory use very close to ivars
    * access speed very close to ivars
    * can be used with Faults
    * can be used with generic objects

    Andrus

    On Nov 24, 2009, at 9:47 PM, Andrus Adamchik wrote:

    True, but they are still user facing collections (or more
    generally valueholders, as this also works for to-one), that get
    inflated internally as needed. DO faults are singletons of this
    type:

    http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html

    So PO lazy relationship resolving goes like this:

    1. on select, init lazy property with a "hollow" ValueHolder
    2. on ValueHolder value access, inflate ValueHolder with the DB data

    For DO it has an extra step:

    1. on select, init lazy property with a singleton Fault of a type
    corresponding to the relationship semantics
    2. on property access, *replace* Fault with either a hollow
    collection or a target DO (which can be hollow or resolved from
    cache)
    3. on collection or hollow DO value access, inflate them.

    The difference may be subtle, but still essential. First, in DO
    case there's no to-one ValueHolder. Target object is attached
    directly. Also the user never sees the Fault object itself, so we
    can replace it with another object when needed. Among other things
    this allows a major memory optimization, as Fault instances are
    singletons shared by all DOs.

    So all in all, DO design seems more sound (and quite possibly that
    whatever memory we save on using ivars in PO, is getting lost to
    extra and more eager ValueHolders).

    Andrus

    On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote:

    Actually, I don't understand :) PO arc properties are all faults
    (classes
    PersistentObject*)

    2009/11/24 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:

    So ... another attempt at abstract analysis (or an attempt at
    unwinding
    my
    memory...) IIRC the main difference between DO and PO is fault
    handling -
    we
    can store a Fault instance in a map, but not in a typed ivar.
    So PO's
    have
    no concepts of faults at all, and the lifecycle is different.
    DO approach
    is
    more lazy (it won't try to create even a placeholder
    collection until the
    property is accessed), and I prefer it to PO's. Wonder if when
    we
    reconcile
    that somehow, the rest will fall into place on its own??

    (E.g. for PO's, we generate extra boolean "fault" properties
    for each
    relationship, that are checked on every property access?)
    Nice idea, need to think about it. But anyways, this is
    separate task
    May or may not be a separate task. But definitely bigger in scope.

    Andrus

    --
    Andrey

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedApr 2, '09 at 8:29p
activeNov 30, '09 at 11:07a
posts29
users6
websitecayenne.apache.org

People

Translate

site design / logo © 2021 Grokbase