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 <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 - 06:07:30 EST