On 07/04/2008 01:25 PM James Pic wrote:
> 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:
>>>> 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?
I do. Future::
ezcPersistentCacheIdentityMap extend ezcPersistentIdentityMap
{
// Caching
}
// ...
$session = new ezcPersistentIdentitySession(
$realPersistentSession,
$cacheIdentityMap
);
Here you go. Just that we won't realize it right now.
>> 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 );
>>>>> 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?
>>>>>> 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::
$obj = $session->load( 'someClass', 23 );
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.
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.
However, I'll work more on the design on Monday and see if it makes
sense to change this structure.
>>>> 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.
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
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
