Hi,
What is the best way to calculate an MD5 Sum for a set of rows in a table, on a Postgresql server?
-----Message d'origine-----
De : pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] De la part de Scott Marlowe
Envoyé : mardi, 31. mai 2005 18:37
À : rubensoda@inwind.it
Cc : pgsql-general
Objet : Re: [GENERAL] For Tom Lane
On Fri, 2005-05-27 at 09:57, rubensoda@inwind.it wrote:
>
> Thanks for answer Tom
>
> "Consider what happens when the user leaves for lunch"
>
> Well, I've already thought about it.But I'm working with
> VS2003 and disconnected dataset.. so when user edit data he's
> modifying an "old" disconnected row, while real updated row is in the
> database..
> So my strategy would be (as I already written):
>
> 1. refresh data recalling current row from database to the form's
> fields 2. lock the row 3. update modified data in the database through
> stored procedure (function) 4. commit and unlock the row
>
> Have you another idea that could work better with disconnected objects ?
While this ensures that the update is atomic, it doesn't ensure that no one else is trying to edit it at the same time.
What you might want to do is either optimistically lock it, or use application level locking. To use optimistic
locking,you'll need to do something like make an md5 of all the fields being edited, then, right before you write back
thedata, check to see if the md5 you created at the beginning still matches by re-reading the data and md5ing it again.
If it doesn't match, then you can throw a "mid air collision" error, so to speak, and tell them that the record changed
underneaththem, or do some kind of merging / or whatnot.
If you want to do application level locking, then create a field and use that for locks. Just make it a timestamp
fieldand put in the current time value when the lock is taken. When the predetermined timeout occurs, the user lock is
removedby the next person to access it, or offer them chance to, or email the original locker, etc... Handle it the
wayyou want or need to.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster