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