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 : Tue Nov 24 2009 - 14:47:58 EST