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