Hi Tobias!
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.
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.
> I would also more favor making the identity map functionality a
> decorator of ezcPersistentSession. This would allow to potentially add
> more decorators around that.
That's probably the best. Note that the part that I quoted talks about extending
the persistent session class.
> 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.
> > 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.
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
