[Modeling-users] state checking

[Duncan McGreggor]

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.

Any pointers?


--
Duncan M. McGreggor mailto:***@adytum.us
Systems & p 301.698.5032
Applications Engineer m 301.801.0349
AdytumSolutions, Inc. http://adytum.us

[Duncan McGreggor]

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.

Any pointers?


--
Duncan M. McGreggor mailto:***@adytum.us
Systems & p 301.698.5032
Applications Engineer m 301.801.0349
AdytumSolutions, Inc. http://adytum.us

[Sebastien Bigaret]

I currently have very very little time, so please excuse this too short
answer.

Post by Duncan McGreggor
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.

[Duncan McGreggor]

Sebastien,

Please do not apologize! This is wonderful, thank you -- I am untar'ing
it right now. We understand how much work you must have to do, being
such an excellent coder; though you may say this tarball is only a
little, it is actually huge! The work it would have taken for me to do
the same thing would be ridiculous... tons of appreciation! Thanks!

Duncan

Post by Sebastien Bigaret
I currently have very very little time, so please excuse this too short
answer.

Post by Duncan McGreggor
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
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
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
_______________________________________________
Modeling-users mailing list
https://lists.sourceforge.net/lists/listinfo/modeling-users

--
Duncan M. McGreggor mailto:***@adytum.us
Systems & p 301.698.5032
Applications Engineer m 301.801.0349
AdytumSolutions, Inc. http://adytum.us

[Duncan McGreggor]

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

Post by Sebastien Bigaret
I currently have very very little time, so please excuse this too short
answer.

Post by Duncan McGreggor
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
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
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.