Hi!
On 07/06/2008 11:29 AM James Pic wrote:
> 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.
I don't see a reason for it. You still can do it in a second decorator.
Still does not make any sense to me, since the logic for incooperating
the identity map (with or without cache) does not change, but only the
mechanism of the storage.
>>>>>>>> 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?
You do not extend the decorator, but only the inner identity map. Please
do not mix up ezcPersistentIdentitySession and ezcPersistentIdentityMap.
ezcPersistentIdentitySession is the decorator to ezcPersistentSession.
This one receives an instance of ezcPersistentIdentityMap on creation.
The ezcPersistentIdentityMap performs the actual handling of identities,
while the *Session decorates the session object to make use of the *Map.
> 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 ...
I don't see how this fits into our discussion. If you need such a
feature, please open another thread. Beside that there is no need for an
ezcPersistentCacheSession. You only need to implement
::
ezcPersistentCacheIdentityMap extends ezcPersistentIdentityMap
{
// ...
}
and instantiate the session like this::
$innerSession = ezcPersistentSession( // ... );
$session = new ezcPersistentIdentitySession(
$innerSession,
new ezcPersistentCacheIdentityMap()
);
> 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.
ezcPersistentSessionInstance will of course be changed to also allow the
setting of decorated sessions. We'll make an interface for that, which
will be implemented by ezcPersistentSession and
ezcPersistentIdentitySession.
>> 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.
Why do you want to change the *Session overall, if you just need to
change the *Map? That does not make sense to me. Sorry.
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
