Hi all, First of all, great work on the requirements and design of Persistent Object 1.5. It sure has come a long way since 1.0 :) I started a new thread, the other one was becoming a bit crowded..
Here are the comments from the Arab jury: >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. Using a decorator here sounds like a good idea to me. So you will create your session something like this: $session = new ezcPersistentIdentitySession( new ezcPersistentSession() ); right? And you will create an interface that declares all the ezcPersistentSession methods (maybe except the ones that shoul not be callable from the identity session). >------ >Design >------ > >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. You can't do this, you can only give more permissions, not less. I suggest making a real decorator out of the session and not declaring the "difficult" methods in the interface. >The use of the \*FromQuery() methods will therefore result in a complete purge >of the identity map to ensure consistency. Is it not possible to use the WHERE parts of those queries to create a select that will return the affected objects? It will be slower since it uses an extra query of course. Later in the doc you note that the $refetch is dangerous. Isn't purging here in fact exactly the same? >ezcPersistentIdentityMap >======================== > >This class is the internal heart of the identity map enhancement. It handles >all caching and mapping activities globally for a session. > >Users shall usually not access the identity map object directly to fetch cached >objects or add new ones. On the other hand, the identity map should be >replaceable to allow more advanced implementations (e.g. involving the Cache >component). Therefore most methods of this class will public, but marked as >proteced via documentation. What does marking them protected gain you? >- It makes sense to use a decorated select query object to avoid the need for > users to submit the $relations array twice: Once to the createFindQuery() > method and once to the find() method. In ezcPersistentSession, it is > currently required to submit the class name twice, which is redundant anyway. > An idea would be to provide a generally decorated ezcQuerySelect class for > PersistentObject, which would also orphan this redundant submission. How would you do that? ezcQuerySelect has subclasses itself? I'm a bit concerned about performance using this system. With _many_ objects, sorting out the relations etc. could be very time consuming, and I'm slightly wondering how many objects this identity map system can support (especially with deep relations). I think it would be a good idea to test that thoroughly and post the results. If not people could get an unpleasant surprise. Cheers, Frederik -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
