You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2009/11/30 11:09:27 UTC
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 <an...@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
>
>
Re: DO/PO design
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@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
>>>
>>>
>>
>>
>
>
Re: DO/PO design
Posted by Tore Halset <ha...@pvv.ntnu.no>.
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 <an...@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
>>
>>
>
>