Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
On Wed, 25 Jun 2008, Tobias Schlitt wrote: > Please review the design draft and post your comments here. Some comments: Inside this method, first it should be checked if the same find query was already performed earlier. In this case, a cached result set can be returned. You can't really do that, as the data might have changed - unless you empty this whole cache when you run save() (and that's not mentioned). The methods that are not supported by the new class will be declared private and throw an exception is used externally. That doesn't work, you can't lower the visibility in inherited classes. See also the description of ezcPersistentIdentitySession further down. IN Functionality there are lots of nested arrays - our guidelines state that we shouldn't do that but use structs instead. 3. Query cache This is tricky, as you don't really know the often, as it can have parameterized queries for use with prepared statements. Records the set of $relatedObjects to belong to $object. $relatedObjects must all be of the same type. The array may also contain objects that have already been recorded. These are then replaced. WHy do they need to be of the same type? find( ezcQuerySelect $query, string $class, bool $refetch = false ) Shouldn't $refetch be true by default? 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? For example, if the myLocation class defines a persistent attribute $city, an alias myLocation_city will be available. The myAddress->$zip property will be available through the alias myRepsonsible_myAddress_zip. The prefixing with all ascending classes is necessary to avoid conflicts if relations to one class should be resolved in different places. You'd need to check limits for the size of aliases here. - PersistentObject allows multiple relations between the same PHP classes (see design 1.4). This leads to problems in the definition of the $relations array provided to the createFindQuery() method. It needs to be figured out how this information can be encoded there. Can't you simply use the property names instead of the classname of the relation? The property names are unique here. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi Tobias! > 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. 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*. Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Derick Rethans > Sent: 27 June 2008 09:38 > To: Tobias Schlitt > Cc: Bertrand Dunogier; Components > Subject: Re: [Components] [PersistentObject] Design: Identity > map and relation pre-fetching support > > On Wed, 25 Jun 2008, Tobias Schlitt wrote: > > > Please review the design draft and post your comments here. > > Some comments: > > Inside this method, first it should be checked if the same > find query > was already performed earlier. In this case, a cached > result set can be > returned. > > You can't really do that, as the data might have changed - > unless you empty this whole cache when you run save() (and > that's not mentioned). If the database & schema support having rowversions (usually automatically updating timestamps, sqlite has rowids you can use IIRC) you should be able to determine if your object is stale. Jared -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi! On 06/27/2008 10:38 AM Derick Rethans wrote: > On Wed, 25 Jun 2008, Tobias Schlitt wrote: >> Please review the design draft and post your comments here. > Some comments: > Inside this method, first it should be checked if the same find query > was already performed earlier. In this case, a cached result set can be > returned. > You can't really do that, as the data might have changed - unless you > empty this whole cache when you run save() (and that's not mentioned). Yes, that is one possibility. If we don't allow updating / deleting with custom queries, we could simply update the objects in the identity map, which would automatically update them in the query cache, too (only references here). We run into the same problem with the relation cache and the identity map itself, if updates/deletes from custom queries occur. Therefore I suggested to make the affected methods throw an exception if updates/deletes from custom queries are attempted. Clearing the caches sounds better now. > The methods that are not supported by the new class will > be declared private and throw an exception is used externally. > That doesn't work, you can't lower the visibility in inherited classes. > See also the description of ezcPersistentIdentitySession further down. I should remove the "marked as private" part. Throwing an exception should work. However, clearing the caches sounds better. This must only be documented very well. > IN Functionality there are lots of nested arrays - our guidelines state > that we shouldn't do that but use structs instead. I thought a bit about this while writing the design. I agree with you but did not manage to come up with a good design of such structs, yet. Since this is only internal and completly encapsulated by the identity map object, we could still use arrays (for access performance reasons) as we do in rare cases in other components, too. > 3. Query cache > > This is tricky, as you don't really know the often, as it can > have parameterized queries for use with prepared statements. Yes, that is an issue I did not take into account, yet. Any idea how we can solve this? Not cache queries with bound parameters does not sound that good to me, since this is very common usage. > Records the set of $relatedObjects to belong to $object. > $relatedObjects must all be of the same type. The array may also > contain objects that have already been recorded. These are then > replaced. > WHy do they need to be of the same type? Agreed, will change this. > find( ezcQuerySelect $query, string $class, bool $refetch = false ) > Shouldn't $refetch be true by default? Why? The basic idea behind the identity map is to perform less database access. In general, you only need to fetch the query result once and only refetch if it is really necessary. > 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? No. It may happen, that a class name occurs multiple times even on different levels of the array. But this is no real recursion, since you can only define an iterative depth in the structure. An example would be: array( 'myPerson => array( 'myPerson' => array( 'myPerson' => true ) ) ) Thiś would fetch contact relations to the depth of 3. > For example, if the myLocation class defines a persistent attribute > $city, an alias myLocation_city will be available. The myAddress->$zip > property will be available through the alias > myRepsonsible_myAddress_zip. The prefixing with all ascending classes > is necessary to avoid conflicts if relations to one class should be > resolved in different places. > You'd need to check limits for the size of aliases here. Yes, I'll add this to the list of open issues. Any idea how to sensibly solve this? > - PersistentObject allows multiple relations between the same PHP > classes (see design 1.4). This leads to problems in the definition of > the $relations array provided to the createFindQuery() method. It > needs to be figured out how this information can be encoded there. > Can't you simply use the property names instead of the classname of the > relation? The property names are unique here. We don't have a reverse lookup here, yet, AFAIR. However, we could introduce it for this purpose. Will check this. Sounds like a plan to me. Thanks for your input! 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
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi James!
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?
I would also more favor making the identity map functionality a
decorator of ezcPersistentSession. This would allow to potentially add
more decorators around that.
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.)
> 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?
Thanks for your input.
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
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi Jared! On 06/27/2008 12:33 PM Jared Williams wrote: >> On Wed, 25 Jun 2008, Tobias Schlitt wrote: >>> Please review the design draft and post your comments here. >> Some comments: >> >> Inside this method, first it should be checked if the same >> find query >> was already performed earlier. In this case, a cached >> result set can be >> returned. >> >> You can't really do that, as the data might have changed - >> unless you empty this whole cache when you run save() (and >> that's not mentioned). > If the database & schema support having rowversions (usually automatically > updating timestamps, sqlite has rowids you can use IIRC) you should be able > to determine if your object is stale. I don't know how this could help in our case. Could you elaborate a bit more on your idea? Beside that, AFAIK not all databases support row IDs (e.g. MySQL). Since PersistentObject is an abstraction layer, we cannot really rely on such features. Regard, 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
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
> -Original Message- > From: Tobias Schlitt [mailto:[EMAIL PROTECTED] > Sent: 28 June 2008 17:38 > To: Jared Williams > Cc: 'Derick Rethans'; 'Bertrand Dunogier'; 'Components' > Subject: Re: [Components] [PersistentObject] Design: Identity > map and relation pre-fetching support > > Hi Jared! > > On 06/27/2008 12:33 PM Jared Williams wrote: > > >> On Wed, 25 Jun 2008, Tobias Schlitt wrote: > > >>> Please review the design draft and post your comments here. > > >> Some comments: > >> > >> Inside this method, first it should be checked if the same find > >> query > >> was already performed earlier. In this case, a cached result set > >> can be > >> returned. > >> > >> You can't really do that, as the data might have changed - > unless you > >> empty this whole cache when you run save() (and that's not > >> mentioned). > > > If the database & schema support having rowversions (usually > > automatically updating timestamps, sqlite has rowids you > can use IIRC) > > you should be able to determine if your object is stale. > > I don't know how this could help in our case. Could you > elaborate a bit more on your idea? > > Beside that, AFAIK not all databases support row IDs (e.g. > MySQL). Since PersistentObject is an abstraction layer, we > cannot really rely on such features. > Its similar to optimistic locking. Wheras an optimistic locking prevents updating if a rowversion has changed, using it with reads/selects ensures your cached objects are still valid. The table & object within the id-map has a timestamp or a sequence number, aka rowversion So when perform a query, obviously use the primary key to retrieve the object from the id-map. Then compare the cached rowversion with the returned rowversion to determine whether you need to replace the object. Jared -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Jared Williams a écrit : -Original Message- From: Tobias Schlitt [mailto:[EMAIL PROTECTED] Sent: 28 June 2008 17:38 To: Jared Williams Cc: 'Derick Rethans'; 'Bertrand Dunogier'; 'Components' Subject: Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support Hi Jared! On 06/27/2008 12:33 PM Jared Williams wrote: On Wed, 25 Jun 2008, Tobias Schlitt wrote: Please review the design draft and post your comments here. Some comments: Inside this method, first it should be checked if the same find query was already performed earlier. In this case, a cached result set can be returned. You can't really do that, as the data might have changed - unless you empty this whole cache when you run save() (and that's not mentioned). If the database & schema support having rowversions (usually automatically updating timestamps, sqlite has rowids you can use IIRC) you should be able to determine if your object is stale. I don't know how this could help in our case. Could you elaborate a bit more on your idea? Beside that, AFAIK not all databases support row IDs (e.g. MySQL). Since PersistentObject is an abstraction layer, we cannot really rely on such features. Its similar to optimistic locking. Wheras an optimistic locking prevents updating if a rowversion has changed, using it with reads/selects ensures your cached objects are still valid. The table & object within the id-map has a timestamp or a sequence number, aka rowversion Oracle does not have a "rowid" id/timestamp for this (oracle standard rowid pseudocolumn is actually a row identifier, not row version identifier, guaranteed to be unique only within the table itself). In Oracle 11g there is the ORA_ROWSCN that could be used to identify this (http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/pseudocolumns007.htm#BABFAFIC), but if we have to be compatible back to version 9 (which imho we really should, as oracle installs tend to upgrade very conservatively), we cannot rely on it. The simplest thing working for all versions would be to add a "rowid" column to the table, and a trigger+sequence that updates the value upon updates, same as we do for autoincrement colums. I would say using integers guarantees better consistency than timestamps - timestamps in oracle can go up to 9 digits precision (as in fractions of a second), with 6 digits being the default. But I also like to always add a LastModified column to all my tables, just for traceability... So when perform a query, obviously use the primary key to retrieve the object from the id-map. Then compare the cached rowversion with the returned rowversion to determine whether you need to replace the object. Jared -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
> Oracle does not have a "rowid" id/timestamp for this (oracle > standard rowid pseudocolumn is actually a row identifier, not > row version identifier, guaranteed to be unique only within > the table itself). > > In Oracle 11g there is the ORA_ROWSCN that could be used to > identify this > (http://download.oracle.com/docs/cd/B28359_01/server.111/b2828 > 6/pseudocolumns007.htm#BABFAFIC), but if we have to be > compatible back to version 9 (which imho we really should, as > oracle installs tend to upgrade very conservatively), we > cannot rely on it. > > The simplest thing working for all versions would be to add a > "rowid" column to the table, and a trigger+sequence that > updates the value upon updates, same as we do for > autoincrement colums. I would say using integers guarantees > better consistency than timestamps - timestamps in oracle can > go up to 9 digits precision (as in fractions of a second), > with 6 digits being the default. But I also like to always > add a LastModified column to all my tables, just for traceability... > Ah I should've explained was using timetamps on SQL Server. MSSQL used the term timestamp for its rowversion datatype, but they were 8 byte values, not the usual/standard timestamp. In 2000 a synonym called rowversion was added, and deprecated the use of the timestamp datatype. Jared -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi! I updated the identity map design after discussion here on the list as follows: - Removed the query caching (due to problems with bound paramaters). - Changed the ezcPersistentIdentitySession to be a decorator for ezcPersistentSession instead of extending it. - Removed the $refetch parameters for methods. Refetching should be activated globally. Access is therefore granted to the identity map itself. Open points are still: - Since ezcPersistentIdentitySession only decorates ezcPersistentSessions, it is not seamlessly possible to replace both in an application: Instanceof checks will not work. - loadIfExists() can return null. Should this result be cached or should the method try to load again if no object has been loaded successfully, yet? Thanks for further comments, Cheers! 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
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi Tobias!
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.
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.
> I would also more favor making the identity map functionality a
> decorator of ezcPersistentSession. This would allow to potentially add
> more decorators around that.
That's probably the best. Note that the part that I quoted talks about extending
the persistent session class.
> 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.
> > 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.
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi James!
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?
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?
>> 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?
>>> 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;
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?
Thanks for the discussion.
Chee
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
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
>>
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
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
>
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
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
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
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
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi Tobias!
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.
> > 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?
Actually, it's my fault again! i missed that factorization should be
though of at a later stage, when the session will have enough optionnal
features.
> >> 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::
cache->loadIfExists( $class, $id )
}
}
BTW, does it really correspond to the PHP object model to extend the decorated
class?
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 ...
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.
> 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 ins
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
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::
>
> 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
