Re: [Modeling-users] state checking

[Duncan M. <du...@ad...>]

Sebastien,

Thanks again; this works perfectly -- just what we needed. In case =20
anyone else has similar needs, here's how we are using it:

class EditorContext(EditingContext):
     '''
     This class is a wrapper for EditingContext, whose sole purpose is =
to
     set the optimistic locking behind the scenes and provide a simple
     interface to users of this code.
     '''
     def __init__(self):
         EditingContext.__init__(self)
         self.snapshot_sum =3D ''
         self.protect_data =3D 0

     def fetchData(self, entityName, qualifier=3DNone, isDeep=3D0, =20
rawRows=3D0):
         fs=3DFetchSpecification(entityName, qualifier=3DNone, =20
sortOrderings=3D(), distinctFlag=3D0, deepFlag=3D0, hints=3D{})
         =20
dbContext=3Dself.rootObjectStore().objectStoreForFetchSpecification(fs)
         dbContext.setUpdateStrategy(UPDATE_WITH_OPTIMISTIC_LOCKING)
         return self.fetch(entityName, qualifier=3DNone, isDeep=3D0, =20
rawRows=3D0)

     def commitChanges(self):
         try:
             self.saveChanges()
         except Modeling.Adaptor.OptimisticLockingFailure, e:
             raise DatabaseObjectStateError, e


On Jul 6, 2004, at 2:08 PM, Sebastien Bigaret wrote:

>
> I currently have very very little time, so please excuse this too =
short
> answer.
>
> Duncan McGreggor <du...@ad...> wrote:
>> Hey folks,
>>
>> I am aware that checking for changes in a database source data is not
>> supported yet, but I am attempting to do this anyway...
>>
>> What I want to do is a fetch, and then operate on the data, then =20
>> before I
>> save the changes, fetch again to see if the source has changed at =20
>> all. I
>> have methods that do this, however... the data seems to be cached =20
>> during the
>> call to EditingContext(), as the fetch pulls the same data over and =20=

>> over,
>> not matter how much I change the source data.
>
> Fine! --> what you need here is (again!) definitely optimistic =
locking.
>
> To answer your questions: yes, row snapshots are cached, and this =
leads
> to the limitation you already noticed.  Is there an easy way to get a
> fresh snapshot? Sorry, not in the current state.
>
> I initially thought this was somewhere on a branch, but the recent
> discussion we had with Ernesto proved that this only lies on my
> hard-disk.
>
>   I believe that you want to go this way because you need it; same as
>   for Ernesto.
>
> I've put there a tarball containing the current state for optimistic
> locking:
> https://sourceforge.net/tracker/index.php?=20
> func=3Ddetail&aid=3D986122&group_id=3D58935&atid=3D489338
>
> There's a patch against the current CVS head and some additional
> files, full content is:
>
>     optimistic_locking.patch
>     Modeling/DefaultEditingContextDelegate.py
>     Modeling/EditingContextDefaultDelegate.py
>     Modeling/interfaces/EditingContextDelegate.py
>     Modeling/tests/test_EditingContext_optimistic_locking.py
>
> I'm sorry I've not enough time to comment right now, but at least it =
is
> functional; you can refer to the tests that are contained in module
> test_EditingContext_optimistic_locking.py
>
>   Hopefully this will be a good starting point for all of you needing
>   the feature; please just keep in mind this is alpha software. Any
>   feedbacks will be greatly appreciated!
>
> Last: by now I cannot give a exhaustive overview of the current
> limitations, however the tests comment some of these.  Plus, do not =
try
> to make it work w/ nested ECs unless you know what you're doing (and
> since I've no time to check this right now, I'd say I do not know what
> sort of weird effects you can get if you try this with nested ECs!).
>
> -- S=E9bastien.=