R
Rob Fitzpatrick
Guest
Enhancement request: Add a new database data type called "rowversion" Brief description: A ROWVERSION field is similar to an INT64 in terms of its storage representation on disk. Unlike an INT64, its value cannot be changed by an ABL or SQL client; it can only be read. Every time the record is updated by any client, the field's value is incremented monotonically by an internal database trigger. Use case: To aid in implementing an optimistic-locking strategy. For example, an app server sends records to the front end. The client chooses to update one of the records, calling an API endpoint to POST the new data. The application then needs a way to check that the version of the record that the client saw is still the current version, to avoid clobbering an intervening change to that record by some other user, if any. Ideally, the record that the client received contains a ROWVERSION field. The client then passes it back to the back end in the POST. The app server can then re-read the record and compare its ROWVERSION with that in the POST request. If they match then the record remains unmodified since the original read and the update can be applied. If they do not match then the server replies to the client with an error, e.g. a 409, indicating that the update was not processed. In the absence of a ROWVERSION data type, row versioning functionality has to be implemented programmatically on the app server, e.g. by RAW-TRANSFER of the buffer contents to a RAW field, and then hashing the RAW field's contents with MESSAGE-DIGEST.
Continue reading...
Continue reading...