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
[email protected]
http://lists.ez.no/mailman/listinfo/components
