Oleg Broytmann wrote:
Hello!
1) Should I email the group about my design idea for optimistic
locking, or should I just write tests and code and see how it works?
IWBN to do both.
Ok, I've spent a bit of time going through the code and some test cases.
In general, I've seen three methods in the past work for optimistic
concurrency:
1. Use a timestamp or sequence field that is automatically updated
by the database whenever an update is made to the row. The calling
program pulls this column on the initial SELECT and then passes it back
in the UPDATE in the WHERE clause. If the timestamp or sequence is
different from the original select, the UPDATE fails.
2. Use a timestamp or sequence field that the application is
responsible for updating. This is the same as #1 above, but has the
disadvantage of requiring each accessing application or person to
remember to update that field.
3. Keep a copy of each field from the original SELECT in the
application, and then append it to the WHERE clause on the UPDATE. This
works, but has the disadvantages of requiring additional memory to keep
the original values, and of the additional network traffic associated
with the fatter UPDATE statement.
Given what I've seen with SQLObject I think option (3) makes the most
sense. Primarily because it will be difficult and error prone to use
different logic for the different database types, I think option (1) is
out. I think option (2) is too prone to error from the case when
non-SQLObject clients are accessing a database at the same time that
SQLObject is. This is probably rare in most cases, but it's definitely
a foreseeable condition.
So unless anyone sees this differently I'll probably write the code to
do option (2), which is to pass the original column values in the WHERE
clause on the UPDATE.
Question--where's the best place in SQLObject to grab the original
values during the SELECT()? I've done some pretty detailed debugging
and I think the answer is in the SQLObject.get() class method. I'll
probably add the code immediately after the cache call returns None,
which triggers a call to the database.
Does this seem right?
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
sqlobject-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
