Re: state checking

Duncan McGreggor <[email protected]> Wed, 7 Jul 2004 00:39:48 -0400
Newsgroups gmane.comp.python.modeling
Message-ID <[email protected]>
Sebastien,

Thanks again; this works perfectly -- just what we needed. In case  
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 = ''
         self.protect_data = 0

     def fetchData(self, entityName, qualifier=None, isDeep=0,  
rawRows=0):
         fs=FetchSpecification(entityName, qualifier=None,  
sortOrderings=(), distinctFlag=0, deepFlag=0, hints={})
          
dbContext=self.rootObjectStore().objectStoreForFetchSpecification(fs)
         dbContext.setUpdateStrategy(UPDATE_WITH_OPTIMISTIC_LOCKING)
         return self.fetch(entityName, qualifier=None, isDeep=0,  
rawRows=0)

     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 <[email protected]> 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  
>> before I
>> save the changes, fetch again to see if the source has changed at  
>> all. I
>> have methods that do this, however... the data seems to be cached  
>> during the
>> call to EditingContext(), as the fetch pulls the same data over and  
>> 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? 
> func=detail&aid=986122&group_id=58935&atid=489338
>
> 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ébastien.


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com