Hi Tobias! > 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. 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*. Regards, James. -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
