On Apr 9, 3:24 pm, "Aaron D. Gifford" <[email protected]> wrote:
> How will your proposed strict_modification? flag handle concurrent
> non-transactional row changes like this:
>
> Process A loads an instance of Foo from the database
>
> Process B updates the table row the Foo instance refers to changing
> field bar from value "oldbar" to value "newbar" but process A doesn't
> know about this update.
>
> Process A executes an UPDATE to the Foo instance, changing the value
> from "oldbar" to "newbar".  Process A's update sees that ZERO rows
> were changed (because a different process already updated the value to
> the new value).
>
> Will Process A raise an exception in this case,even though the value
> of the Foo object has the expected new value?

Dataset#update is supposed to return the number of rows modified.  In
any case where you are using Sequel objects, this should only be 1
row, since the instance's filter is done looking for a specific
primary key value.

If process A does:

  UPDATE a SET name = 'newbar' WHERE id = 1;

and shortly thereafter process B does:

  UPDATE a SET name = 'newbar' WHERE id = 1;

Both processes should have the dataset return 1.  I believe this is
true on most databases, but I could be wrong.

What this will prevent is:

If process A does:

  DELETE FROM a WHERE id = 1;

and shortly thereafter process B does:

  UPDATE a SET name = 'newbar' WHERE id = 1;

process B will have an error raised, instead of not realizing that the
row didn't exist.  Technically, the update statement worked.  It is
valid SQL and doesn't cause any errors.  However, it also doesn't
modify any rows, since the row with id 1 was already deleted.  This is
what I think should raise an error.

Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sequel-talk?hl=en.

Reply via email to