DO/PO design

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Nov 30 2009 - 05:09:27 EST

  • Next message: Tore Halset: "Re: DO/PO design"

    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 <andru..bjectstyle.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
    >
    >



    This archive was generated by hypermail 2.0.0 : Mon Nov 30 2009 - 05:10:00 EST