Hi!
On 06/27/2008 10:38 AM Derick Rethans wrote:
> 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).
Yes, that is one possibility. If we don't allow updating / deleting with
custom queries, we could simply update the objects in the identity map,
which would automatically update them in the query cache, too (only
references here). We run into the same problem with the relation cache
and the identity map itself, if updates/deletes from custom queries occur.
Therefore I suggested to make the affected methods throw an exception if
updates/deletes from custom queries are attempted. Clearing the caches
sounds better now.
> 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.
I should remove the "marked as private" part. Throwing an exception
should work. However, clearing the caches sounds better. This must only
be documented very well.
> IN Functionality there are lots of nested arrays - our guidelines state
> that we shouldn't do that but use structs instead.
I thought a bit about this while writing the design. I agree with you
but did not manage to come up with a good design of such structs, yet.
Since this is only internal and completly encapsulated by the identity
map object, we could still use arrays (for access performance reasons)
as we do in rare cases in other components, too.
> 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.
Yes, that is an issue I did not take into account, yet. Any idea how we
can solve this? Not cache queries with bound parameters does not sound
that good to me, since this is very common usage.
> 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?
Agreed, will change this.
> find( ezcQuerySelect $query, string $class, bool $refetch = false )
> Shouldn't $refetch be true by default?
Why? The basic idea behind the identity map is to perform less database
access. In general, you only need to fetch the query result once and
only refetch if it is really necessary.
> 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?
No. It may happen, that a class name occurs multiple times even on
different levels of the array. But this is no real recursion, since you
can only define an iterative depth in the structure. An example would be:
array(
'myPerson => array(
'myPerson' => array(
'myPerson' => true
)
)
)
Thiś would fetch contact relations to the depth of 3.
> 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.
Yes, I'll add this to the list of open issues. Any idea how to sensibly
solve this?
> - 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.
We don't have a reverse lookup here, yet, AFAIR. However, we could
introduce it for this purpose. Will check this. Sounds like a plan to me.
Thanks for your input!
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
[email protected]
http://lists.ez.no/mailman/listinfo/components
