Hi,
> > Later in the doc you note that the $refetch is dangerous. Isn't
> > purging here in fact exactly the same?
>
>
> Yes, it is. If $refetch is turned on or the cache is purged, the user
> needs to take care that the identities - of which he still holds
> references to - get unset properly.
>
> I don't see a real choice here, do you? The problem is, that people can
> use find() queries to read objects from the DB that might already be
> loaded. In this case you need to decide if the loaded objects should be
> replaced with their existing identity (normal case) or if you want them
> to be reloaded. The latter case is usefull in case you want to update
> multiple objects i case the database might have changed. This is quite
> cumbersome with the refresh() method, since it uses single SELECT queries.
>
> I think a solution here might be to replace just the values of existing
> identities, in case $refetch is true. This might be a bit slower and
> propably requires us to make some more parts of ezcPersistentSession as
> public (and document them as protected of course).
>
> Another problem is the refetching of relations here. The second part of
> the design describes how pre-fetching of related objects will work. This
> makes use of the identity map to store the results of the pre-fetch and
> return them if getRelatedObjects() is called. However, people might want
> to limit the pre-fetched result set using a WHERE condition. Then the
> getRelatedObjects() method will not return the result set it would
> usually have returned, but a limited one. In case the user wants to
> fetch the original result set later, he needs the re-fetching mechanism.
It makes sense and I don't really see any other options as long as we
don't have any means to monitor what people are actually doing with
the objects.
One thing, if the cache is purged.. it would be nice if there was a
way that you could discover this later as the only rule you really
have is "don't use objects not from the cache". If then the cache is
purged without you knowing about it that could be bad. Maybe even a
callback or a signal could be useful.
> >> 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?
>
>
> Preventing users from doing really dangerous stuff (adding objects
> manually to the map, etc.). They still can do, but they notice that they
> are not supposed to.
But the object is not easily available to the users anyway is it?
(Unless I missed it).
>
> >> - 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.
Ah, sorry.. I was talking about the general identity map system here.
Not the ezcQuerySelect wrapping.
>
> I don't think the performance drawback will be that hard. I imagine
> something like
>
> ezcPersistentFindQuery
> {
> protected $selectQuery;
>
> public function __construct( ezcQuerySelect $select )
> {
> $this->selectQuery = $select;
> }
>
> public function __call( ... )
> {
> // Dispatch to $this->selectQuery
> }
>
> public function __get( ... )
> {
> // Dispatch to $this->selectQuery
> }
> // ... __set(), __isset(), __unset(),...
> }
Yep, this makes sense..
Cheers,
Frederik
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
