Open Grauenwolf opened 8 years ago
Will this require a new value on the Update (and Upsert?) option flags?
We'll want to support date/time columns (e.g. LastUpdatedDate) as well.
Do we want to include an audit rule to turn this on universally? Do we want to include an OnConflict event?
I think that both database provided timestamp and user managed counter/datetime checks are necessary and should be provided by the library. Original value check (all columns, changed columns only?) could also come handy in some use cases.
Yes for an audit rule but it should be overridable on operation level. Juggling with two data sources or data models to change concurrency handling would be awkward.
IMO concurrency conflict should be treated as an error - calling OnExecutionError and throwing a DataConcurrencyException with table and key info.
Server side concurrency column update
Client side concurrency column update
This feature would only be used for updates, not upserts. (The assumption here is that if you are doing an upsert, you don't know if the row already exists. Thus you can't know what the concurrency column value would be.)
If no rows were detected as being updated, we'll assume that the concurrency check failed. This doesn't sound right at first, but if the row doesn't exist at all that's because someone deleted it out from under us. So it's still a concurrency violation.
DataConcurrencyException
Either the concurrency column [ColumnName] doesn't match or the row being updated no longer exists.
DataConcurrencyException already exists.
This would be used for concurrency control scenarios.
One possible implementation is the use of timestamp columns (called rowersion in SQL Server).
https://msdn.microsoft.com/en-us/library/ms182776.aspx?f=255&MSPPError=-2147217396
NPoco equivalent https://github.com/schotime/NPoco/wiki/Version-column-support