cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: DO/PO design
Date Mon, 30 Nov 2009 11:06:46 GMT
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
>>>
>>>
>>
>>
>
>


Mime
View raw message