On Wed, 25 Jun 2008, Tobias Schlitt wrote:
Please review the design draft and post your comments here.
Some comments:
Inside this method, first it should be checked if the same find query
was already performed earlier. In this case, a cached result set can be
returned.
You can't really do that, as the data might have changed - unless you
empty this whole cache when you run save() (and that's not mentioned).
The methods that are not supported by the new class will
be declared private and throw an exception is used externally.
That doesn't work, you can't lower the visibility in inherited classes.
See also the description of ezcPersistentIdentitySession further down.
IN Functionality there are lots of nested arrays - our guidelines state
that we shouldn't do that but use structs instead.
3. Query cache
This is tricky, as you don't really know the query often, as it can
have parameterized queries for use with prepared statements.
Records the set of $relatedObjects to belong to $object.
$relatedObjects must all be of the same type. The array may also
contain objects that have already been recorded. These are then
replaced.
WHy do they need to be of the same type?
find( ezcQuerySelect $query, string $class, bool $refetch = false )
Shouldn't $refetch be true by default?
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?
For example, if the myLocation class defines a persistent attribute
$city, an alias myLocation_city will be available. The myAddress-$zip
property will be available through the alias
myRepsonsible_myAddress_zip. The prefixing with all ascending classes
is necessary to avoid conflicts if relations to one class should be
resolved in different places.
You'd need to check limits for the size of aliases here.
- 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.
Can't you simply use the property names instead of the classname of the
relation? The property names are unique here.
regards,
Derick
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
