...
- We definitely want to guarantee that every distinct blob ever at a particular object ID will have a distinct version number, even across generations. (Ask Ryan for his lock example.)
- We probably also want to guarantee that version numbers for a particular object ID monotonically increase over time. This allows us to efficiently compare two version numbers and tell which one is more recent.
- We might also want to guarantee that the version number of an object increases by exactly one when it is updated. This allows clients to accurately predict the version numbers that they will write. (Ask Diego for his client-side transactions example.)
The current code guarantees (1) and (2) in the following way:
- There's a "master vector clock" per table which contains the next available version number for that table. This is initialized to a small integer when the table is created and is recoverable after crashes (see Recovery).
- When an object is created or updated, its new version number is set to the value of the master vector clock for that table, and the master vector clock is incremented.
- Nothing special happens when an object is deleted.