You can use a simple 'L' flag on the rows you want locked and add a
where to don't touch them.
I'm afraid things are more complicated in many real-world cases.
Locking a single row isn't enough.
What if the UPDATE or DELETE forces deep changes in one or more indices?
What if the UPDATE or DELETE cascades to 1 to N levels?
What if some change launches a trigger that itself changes things
elsewhere, possibly a LOT of things, that may themselves change several
other parts of the DB?
In all cases above, if a read operation occurs in the middle of the
write process, DB integrity is jeopardized.
I haven't looked at the proposed patch but I seriously doubt all of
this is taken care in all situations.
JcD
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
