Hi James!
On 07/01/2008 05:53 PM James Pic wrote:
> Tobias Schlitt wrote:
>> On 06/27/2008 11:44 AM James Pic wrote:
>>>> The Identity Map support should be optional to not break BC and keep
>>>> flexibility. Therefore, a new class named ezcPersistentIdentityMapSession
>>>> is
>>>> implemented. This extends the current implementation ezcPersistentSession
>>>> to
>>>> make instanceof checks still work. All of the methods will be overwritten
>>>> and
>>>> new handler classes, extending the existing ones will be implemented to
>>>> reflect
>>>> the actual additions. The methods that are not supported by the new class
>>>> will
>>>> be declared private and throw an exception is used externally.
>>> Are we sure that we don't want the persistent object session to allow
>>> setting a handler chain?
>>> This could allow extending PersistentObject, and creating new handlers, not
>>> only
>>> for the identity map, but for example with tie-ins of other components
>>> than Database, like Cache or SignalSlot.
>> I don't really get your idea of a handler chain. Could you elaborate a
>> bit more on this?
> It would be a list of handlers with priorities, but that's not a good idea.
> I wanted to cache persistent objects, which can be particularely
> interresting when pre-fetch support.
This should be easy to implement by replacing the identity map itself in
the ezcPersistentIdentitySession. I also thought about caching while
designing it. Do you see any problem here?
Beside that, you could still add a new decoration layer around it, if
this solution is not feasible.
> Also, i wanted to emit a signal connected to a slot that would make
> statistiques
> with persistent session queries, in the context of an application audit.
That sounds like an interessting idea. However, I think sending signals
in multiple places could be quite a performance issue within the
persistent session. How would you like to have it implemented?
>> I also discussed the idea of making a PersistentObjectCacheTiein with
>> some people at the conference. Looks like there is need for it. However,
>> in the current design this could be realized by offering a different
>> implementation of the ezcPersistentIdentityMap class, which handles the
>> actual mapping. (Note, this is not the ezcPersistentSession decorating
>> class, but the storage used by it.)
> Ok, i understand that it would make sense to use Cache "crud" handlers, but a
> decorator for signal-slot.
I don't get the point here, could you enlighten me, please?
>>> Derick Rethans wrote:
>>>> On Wed, 25 Jun 2008, Tobias Schlitt wrote:
>>>>> Please review the design draft and post your comments here.
>>>> The keys of the array structure represent persistent class names. A
>>>> key might either be assigned to the value true or to another array of
>>>> relatives to fetch. True means "fetch the desired relatives, but no
>>>> further ones in this direction". An array as the value describes to
>>>> fetch further relatives for the relative.
>>>>
>>>> Is this array structure recursive?
>>> Why wouldn't the identity map hold a simple list of identity objects?
>>> Each object would have an identity object.
>>> The identity object would hold the class name, id, and id-property name
>>> of the object, as well as the related objects *identities*.
>> How would you realize a lookup the, if objects are loaded by class name
>> and ID? This would require iteration over all these mapping objects, if
>> I got the idea correct.
>>
>> Example:
>>
>> foreach ( $identityObjects as $identity )
>> {
>> if ( $identity->class == $reqClass && $identity->id == $reqId )
>> {
>> return $identity->object;
>> }
>> }
>>
>> instead of
>>
>> if ( isseet( $identityMap[$class][$id] ) )
>> {
>> return $identityMap[$class][$id];
>> }
>> return null;
>>
>> The latter one runs in O(1) whhile the first one runs in O(n).
>>
>> Or did I understand you incorrectly?
> No, i did not submit my input correctly, please excuse me for that.
> The latter lookup code is better, of course.
> Encapsulating some of the persistent object informations in the identity
> object
> could allow some latter optionnal extensions:
> - identity object has the list of identities from related objects,
> - state modification tracking.
The list of related objects can be looked up in the same manor as shown
above, but in the $relationMap array:
if ( isseet( $relationMap[$class][$id][$relatedClass] ) )
{
return $identityMap[$class][$id][$relatedClass];
}
return null;
The problem with tracking state modifications is, that we would need to
deliver the identity object to the user, then. Otherwise I don't see a
poissbility here, beside storing each object twice and comparing them.
Both solutions are not possible: Giving the user an instance of an
object he did not require is un-nice and a BC break, duplicating the
consumed RAM is a big no-no. Or did I miss a possibility?
Thanks for the discussion.
Cheers,
Toby
--
Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards
Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer
[EMAIL PROTECTED] | eZ Systems AS | ez.no
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
