Hi James!
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.
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). If a requested identity is not found it first checks the cache for
the identity and finally fetches it from the DB.
>>> 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.
>>>> 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?
> I admit that using handlers for SignalSlot was a mistake, a decorator or child
> should be used to emit signals.
Exactly.
>> 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.
>> 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.
> 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.
Regards,
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
