Hi Tobias!
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:
> >>> Tobias Schlitt wrote:
> >>>> On 06/27/2008 11:44 AM James Pic wrote:
>
> >>>>>> The Identity Map support should be optional to not break BC and keep
> >>>>>> flexibility. Therefore, a new class named
> >>>>>> ezcPersistentIdentityMapSession is
> >>>>>> implemented. This extends the current implementation
> >>>>>> ezcPersistentSession to
> >>>>>> make instanceof checks still work. All of the methods will be
> >>>>>> overwritten and
> >>>>>> new handler classes, extending the existing ones will be implemented
> >>>>>> to reflect
> >>>>>> the actual additions. The methods that are not supported by the new
> >>>>>> class will
> >>>>>> be declared private and throw an exception is used externally.
>
> >>>>> Are we sure that we don't want the persistent object session to allow
> >>>>> setting a handler chain?
> >>>>> This could allow extending PersistentObject, and creating new handlers,
> >>>>> not only
> >>>>> for the identity map, but for example with tie-ins of other components
> >>>>> than Database, like Cache or SignalSlot.
>
> >>>> I don't really get your idea of a handler chain. Could you elaborate a
> >>>> bit more on this?
>
> >>> It would be a list of handlers with priorities, but that's not a good
> >>> idea.
> >>> I wanted to cache persistent objects, which can be particularely
> >>> interresting when pre-fetch support.
>
> >> This should be easy to implement by replacing the identity map itself in
> >> the ezcPersistentIdentitySession. I also thought about caching while
> >> designing it. Do you see any problem here?
>
> > Do we want to cache the complete identity map(s) in order to load it in the
> > persistent session for another server-request;
> > or do we want to cache individual identities?
>
> This is your choice actually. :) I think we won't provide a tiein with
> Cache for the upcoming release, since there is too much other stuff to
> do. However, you can still build that on your own for custom use.
I though that we had to keep in mind the future caching features while
designing?
> 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?
> >>> 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?
> >>>> 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.
> >> 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?
However, as long as you think that it's maintainable and flexible enough to
implement features, i don't see the problem ;)
> >> 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.
> > Getting the identity objects from the session, if possible, should be done
> > in new methods; however, in the implementation i did on my own, only the
> > session decorator uses them identity objects.
>
> > Note that you might not want to track all changes in the state. Having the
> > previous state of an object is sufficient to prevent useless update or
> > select
> > queries.
>
> Having the session automatically check if an update I want to perform is
> sensible sounds like too much magic for my taste. Sorry. This can be
> part of the application and does not belong to the component.
You're probably right, but i'm sorry that you feel sorry.
Regards, James.
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
