SQL Stored procs without timestamp/prior data.

Rayk posted on Tuesday, September 19, 2006

Is the timestamp field and sending previous data to the UPDATE command essential to CSLA, or is that just part of the CodeSmith implementation?   I bought the book (both older and new actually), but sometimes I have trouble figuring out what is 'new CSLA' and what is an 'add-on'. 

My current database tables do not have timestamp fields in them.  This is mostly because it is an older DB design, but also because some fields get updated in the background by another process.  (Specifically, an ETA and new location may be updated in the background).

Also, because of this, I cannot send every field back to the table on an UPDATE. 

Does anybody do anything different, and is it tough to modify CSLA to do this?

Thanks,

- RayK

RockfordLhotka replied on Tuesday, September 19, 2006

The use of timestamps is up to you, and is not required by CSLA at all.

CSLA does not directly manage concurrency. It is up to you to manage concurrency, and timestamps are one of the most common and efficient ways to do this. However, there certainly are cases where you can't change a database to include timestamps on the tables, and then you need to come up with another solution.

One solution is to skip concurrency entirely. In that case you go from "optimistic locking, first write wins" to "optimistic locking, last write wins" - which is often considered a poor approach, but may work for you.

Another solution is to use a CRC/checksum value instead of a timestamp. This is not as safe, because a checksum is merely a hash value, and hash values are not always unique. This technique will usually work, but there's always the possibility of someone overwriting another person's updates.

Yet another solution is to keep a snapshot of all original values when they are read from the database. Then you can compare those values to the database values during the update process. If they all match, then you know that no data has changed in the interrim and you can apply your update. This is a totally safe approach, but essentially doubles the memory consumption of each of your objects (because you have to keep copies of each original data value).

Rayk replied on Friday, September 22, 2006

Thanks Rocky.

I've also had to rethink my 'objects' a bit.  We have one table in particular that contains both user-editable data and 'system-edited' data.  I am having trouble figuring out how to object-orient this little table, but it is clear to me now that it should probably be two objects somehow.  That way, i could still use "optimistic locking, first write wins" on the user-editable portion. 

-RayK