Harald Fuchs wrote:
In article <[EMAIL PROTECTED]>,
Alex Adriaanse <[EMAIL PROTECTED]> writes:
Thanks for the input everyone. I think Harald's approach will work
well...
I'm not so sure anymore :-(
Consider something like that:
UPDATE tbl SET col1 = 1 WHERE col2 = 1;
UPDATE tbl SET col1 =
In article <[EMAIL PROTECTED]>,
Alex Adriaanse <[EMAIL PROTECTED]> writes:
> Thanks for the input everyone. I think Harald's approach will work
> well...
I'm not so sure anymore :-(
Consider something like that:
UPDATE tbl SET col1 = 1 WHERE col2 = 1;
UPDATE tbl SET col1 = 2 WHERE col2 = 1;
w
Thanks for the input everyone. I think Harald's approach will work
well, so I'm planning on doing what he suggested, with a few
modifications. I think I can still use a sequence-backed INTEGER rather
than TIMESTAMP, and have the trigger that sets the revision to NULL also
NOTIFY the daemon th
"Alex Adriaanse" <[EMAIL PROTECTED]> writes
> Applying this analogy to our database, wouldn't that require a
> table-level lock during a CVS-like commit (which would mean locking the
> table, getting the revision number, updating the row(s), and committing
> the transaction)?
>
You may have a loo
In article <[EMAIL PROTECTED]>,
Alex Adriaanse <[EMAIL PROTECTED]> writes:
> I think that would greatly decrease the chances of a race condition
> occurring, but I don't think it'd solve it. What if 150 other
> revisions occur between a row update and its corresponding commit?
How about the foll
Qingqing Zhou wrote:
"Alex Adriaanse" <[EMAIL PROTECTED]> writes
This seems to work, except there exists a race condition. Consider the
following series of events (in chronological order):
1. Initially, in the codes table there's a row with id=1, revision=1,
and a row with id=2, revision
I think that would greatly decrease the chances of a race condition
occurring, but I don't think it'd solve it. What if 150 other revisions
occur between a row update and its corresponding commit?
Alex
Vincent Hikida wrote:
To fetch all updates since the last synchronization, the client would
"Alex Adriaanse" <[EMAIL PROTECTED]> writes
> This seems to work, except there exists a race condition. Consider the
> following series of events (in chronological order):
>
>1. Initially, in the codes table there's a row with id=1, revision=1,
> and a row with id=2, revision=2
>2.
To fetch all updates since the last synchronization, the client would
calculated a value for $lastrevision by running this query on its local
database:
SELECT max(revision) AS lastrevision FROM codes;
It would then fetch all updated rows by running this query against the
server:
SELECT * FROM c
