Hi Tobias!
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?
> Beside that, you could still add a new decoration layer around it, if
> this solution is not feasible.
>
>> 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 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.
I admit that using handlers for SignalSlot was a mistake, a decorator or child
should be used to emit signals.
>>>> Derick Rethans wrote:
>>>>> On Wed, 25 Jun 2008, Tobias Schlitt wrote:
>
>>>>>> Please review the design draft and post your comments here.
>
>>>>> 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?
>
>>>> Why wouldn't the identity map hold a simple list of identity objects?
>>>> Each object would have an identity object.
>>>> The identity object would hold the class name, id, and id-property name
>>>> of the object, as well as the related objects *identities*.
>
>>> How would you realize a lookup the, if objects are loaded by class name
>>> and ID? This would require iteration over all these mapping objects, if
>>> I got the idea correct.
>>>
>>> Example:
>>>
>>> foreach ( $identityObjects as $identity )
>>> {
>>> if ( $identity->class == $reqClass && $identity->id == $reqId )
>>> {
>>> return $identity->object;
>>> }
>>> }
>>>
>>> instead of
>>>
>>> if ( isseet( $identityMap[$class][$id] ) )
>>> {
>>> return $identityMap[$class][$id];
>>> }
>>> return null;
>>>
>>> The latter one runs in O(1) whhile the first one runs in O(n).
>>>
>>> Or did I understand you incorrectly?
>
>> No, i did not submit my input correctly, please excuse me for that.
>> The latter lookup code is better, of course.
>
>> Encapsulating some of the persistent object informations in the identity
>> object
>> could allow some latter optionnal extensions:
>
>> - identity object has the list of identities from related objects,
>> - state modification tracking.
>
> 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?
> 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.
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.
Thanks for your hard work on the new PersistentObject component, which
is critical in order to make an efficient model layer.
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
