Hi Tobias!
Tobias Schlitt wrote:
> On 07/04/2008 01:25 PM James Pic wrote:
> > Tobias Schlitt wrote:
> >> On 07/02/2008 02:11 PM James PIC wrote:
> >>> On Wed, Jul 2, 2008 at 9:19 AM, Tobias Schlitt <[EMAIL PROTECTED]> wrote:
> >>>> On 07/01/2008 05:53 PM James Pic wrote:
> >> If it was for me, we would provide an extended identity map class in a
> >> Cache tiein that maintains a request local identity map (as it does
> >> now).
>
> > Would that really be efficient to fetch a cached state from a file
> > containing
> > 500 thousands of states?
>
> Each identity will be a single file::
>
> $id = "$class__$id";
> $cache->store( $id, $persistentObject );
Can't we do this in a "transparent" manner?
If this was done in a session child or decorator, it could cache reverse
relations as well.
> >>>>> Also, i wanted to emit a signal connected to a slot that would make
> >>>>> statistiques
> >>>>> with persistent session queries, in the context of an application audit.
>
> >>>> That sounds like an interessting idea. However, I think sending signals
> >>>> in multiple places could be quite a performance issue within the
> >>>> persistent session. How would you like to have it implemented?
>
> >>> It would cause some performance loss indeed.
> >>> This would just be used in the context of application audits, which are
> >>> processes with a short lifetime (for example, a week or two).
>
> >> I think writing another decorator which emits signals on each action
> >> sounds like a plan. However, not for 2008.2, although someone comes up
> >> with a contribution for this tiein.
>
> > Sure, but don't we want to keep this in mind while designing?
>
> What do we need to keep in mind here? Another decorator just wraps
> around the normal session or the identity session::
>
> class ezcPersisentSignalSession { // ... }
>
> $sesion = new ezcPersistentSession( // ... );
>
> $identityMap = new ezcPersistentIdentityMap( // ... );
> $identitySession = new ezcPersistentIdentitySession(
> $session,
> $identityMap
> );
>
> $signalSession = new ezcPersistentSignalSession( $identitySession );
> // or
> // $signalSession = new ezcPersistentSignalSession( $session );
>
> Anything I missed?
Actually, it's my fault again! i missed that factorization should be
though of at a later stage, when the session will have enough optionnal
features.
> >>>>>> I also discussed the idea of making a PersistentObjectCacheTiein with
> >>>>>> some people at the conference. Looks like there is need for it.
> >>>>>> However,
> >>>>>> in the current design this could be realized by offering a different
> >>>>>> implementation of the ezcPersistentIdentityMap class, which handles the
> >>>>>> actual mapping. (Note, this is not the ezcPersistentSession decorating
> >>>>>> class, but the storage used by it.)
>
> >>>>> Ok, i understand that it would make sense to use Cache "crud" handlers,
> >>>>> but a
> >>>>> decorator for signal-slot.
>
> >>>> I don't get the point here, could you enlighten me, please?
>
> >>> If identities were cached individually, we could have
> >>> load/delete/read/create
> >>> handlers that would query the Cache component, and not tie the session's
> >>> identity map with the cache.
>
> >> Why won't you implement it simply as e.g. ezcPersistentCacheIdentityMap
> >> extends ezcPersistentIdentityMap. Should be easy to do. What's wrong
> >> with this?
>
> > As far as i'm concerned, i want to use the features of the file-system to
> > optimize the caching. That means that i don't want to fetch all cached
> > states
> > at each request.
>
> You don't. The identity session will request an object from the identity
> map first and the ask the database::
Will the session check on my file system if file /cache/model/someClass/23.php
exists, and use the state returned to make the object::
<?php
class ezcPersistentCacheSession extends ezcPersistentSession // hack for
// ezcPersistentSessionInstance::set()
{
public function load( $class, $id )
{
$this->cache->loadIfExists( $class, $id )
}
}
BTW, does it really correspond to the PHP object model to extend the decorated
class?
Should ezcPersistentCacheSession decorate an instance of its parent, only
because of ezcPersistentSessionInstance?
Maybe allowing the user to set custom/supplied load/delete/update/save handlers
into ezcPersistentSession would:
- fix ezcPersistentSessionInstance problem,
- allow to make custom handlers,
- allow to use supplied handlers like identityMap, cache ...
Of course, it is still possible to make an ezcPersistentSession decorator that
extends ezcPersistentSession to workaround ezcPersistentSessionInstance, and
that would allow setting different handlers. But then we *have* to use
decorators to use supplied processes that could be encapsulated in different
handlers the way the DB handlers are.
> In my idea of a caching identity map, the identity session will work as
> follows:
>
> Loading
> -------
>
> 1. Is someClass with ID 23 in memory? -> Don't fetch anything, just
> return the instance.
> 2. Is someClass with ID 23 in the cache? -> Fetch it from there and
> register the instance in memory.
> 3. Fetch someClass with ID 23 from the DB, store it in the Cache and the
> identity in memory.
>
> Storing
> -------
>
> 1. Store object in DB.
> 2. Register identity in memory.
> 3. Store the object in the cache.
I understand this process, i don't understand why use decorators when we can use
different handlers.
>
> This all can be realized in ezcPersistentCacheIdentityMap as described
> above.
>
> I don't see any problem here.
>
> >>>> The list of related objects can be looked up in the same manor as shown
> >>>> above, but in the $relationMap array:
> >>>>
> >>>> if ( isseet( $relationMap[$class][$id][$relatedClass] ) )
> >>>> {
> >>>> return $identityMap[$class][$id][$relatedClass];
> >>>> }
> >>>> return null;
>
> >>> Will that work without specifying the relationName?
>
> >> Multiple relations to the same class are still a problem I need to
> >> figure out, how to solve. However, shouldn't be that hard, since
> >> ezcPersistentSession already requires you to specify it.
>
> > Then you would have this array:
> > array(
> > $class => array(
> > $id => array(
> > $relatedClass => array(
> > $relationName => array(
> > $state
> > )
> > )
> > )
> > )
>
> > Is there any example in eZ Components where a 5 dimension array was/is used?
>
> Feed does. :) And as a user you don't see anything from it, since it is
> encapsulated in ezcPersistentIdentityMap.
I don't see it as a developer either ... Checked the main classes only.
> >>>> The problem with tracking state modifications is, that we would need to
> >>>> deliver the identity object to the user, then. Otherwise I don't see a
> >>>> poissbility here, beside storing each object twice and comparing them.
> >>>> Both solutions are not possible: Giving the user an instance of an
> >>>> object he did not require is un-nice and a BC break, duplicating the
> >>>> consumed RAM is a big no-no. Or did I miss a possibility?
>
> >>> In terms of ressources, duplicating state arrays would cost, but it would
> >>> allow to make sure that an object state was changed before using the
> >>> update-handler; this could, in certain cases, save database ressources.
>
> >> I think this is up to the user. We already discussed the implementation
> >> of a "unit of work" pattern multiple times and always came to the result
> >> that it has more drawbacks than advantages.
>
> > Can you link me to the discussion please?
> > BTW, i'm talking about encapsulating that in an identity (extended) object,
> > not
> > in the handlers.
>
> Grep the IRC logs of #ezcomponents from the past 1.5 years for the nicks
> "larson" and "tobyS". The main issue here is, that you cannot easily
> determine the order how updates need to happen in terms of database
> consistency. As soon as foreign keys are available we would need to
> perform a topological sort on the relation structure. Maybe we can think
> about this next year or so, again, but for now it is too much work for
> too few benefit. IMHO, of course.
True, we can add 'priority' property to ezcPersistentRelation, and get the
database handlers to make a recursive check.
I understand your point although i don't have this discussion, so i probably
miss something.
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
