Hi James!
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?
I would also more favor making the identity map functionality a
decorator of ezcPersistentSession. This would allow to potentially add
more decorators around that.
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.)
> 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?
Thanks for your input.
Regards,
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
