Hi!
I just went through the design draft I wrote together with Bertrand for
2 new features we plan to implement in PersistentObject 1.5 (2008.2):
- Identity map
- Relation pre-fetching
The identity map feature will avoid to have 2 different objects
representing the same database data in one request. In addition it will
save some duplicate SQL queries if e.g. an object is attempted to be
loaded twice. The relation pre-fetching will allow you to fetch a set oj
objects and their relatives in one query.
The design can be found in SVN
trunk/PersistentObject/design/design-1.5.txt
or rendered to HTML
http://schlitt.info/ez/persistent_object_1.5.html
Please review the design draft and post your comments here. Especially
interessting are the open issues in both designs, so I also paste them here:
Identity map
------------
- Making the identity map a decorator to ezcPersistentSession would
design wise be a nicer solution, but also has some flaws:
- No transparent replacement of current $session objects possible, due
to instanceof checks. Maybe introduce a common interface (would also
allow different implementations of ezcPersistentSession in future)?
- It would make sense to allow the identity mapping session to access
certain protected functionality (creation of queries, execution,
...). This could be solved by making the affected methods public and
documenting them as protected.
- Do we need an option to explicitly reload (load()) an object?
refresh() on the existing version is more logical.
- loadIfExists() can return null. Should this result be cached or should
the method try to load again if no object has been loaded
successfully, yet?
- The updates to perform in the delete() method can become quite time
consuming if all caching facilities are switched on.
- A nice idea would be to enable the replacement of
ezcPersistentIdentityMap with a custom implementation. For example it
could make sense to offer a PersistentObjectCacheTiein to have the
identity map cache objects to disc (request by BD).
Relation pre-fetching
----------------------
- PersistentObject allows multiple relations between the same PHP
classes (see design 1.4). This leads to problems in the definition of
the $relations array provided to the createFindQuery() method. It
needs to be figured out how this information can be encoded there.
- 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.
- Basically, this should be integrated with the
ezcPersistentIdentitySession, because the related objects can then
simply be store in the relation cache and be retrieved using
getRelatedObjects() as usual. This requires only very few code changes
for migrating users (just adding the fetches in a central place).
Thanks ín advance for every input.
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
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
