Erik Holstad schrieb: > Hi Bob! > What would be the use case where you could use an explicit timestamp instead > of using the rowlock? > To me they are used for different things, so what are you planning to to > with them? >
I have a use case, where a big batch of personalized documents are created in a short time (simultaneously on may computers, to be stored then). Instead of keeping all docs in full, I want to store the diff of them only. For this, whenever a doc apprears the first time, I store it in a "master" table. The next store op will then look it up, calculates a diff and keeps it in a "doc" table, together with a the reference to the master doc. As many clients may want to store a master (for the same doc) in a small time period, I use a reference in the form <rowkey.timestamp>. The disadvantage is having a non optimal compression (I may have more than one master copy). But I do not have to lock anything anymore. (It reminds me also on use cases for MySQL's get_last_insert_id() method...) So the return of the Timestamp would help. It means that the Timestamp should be assigned already early in the update code; I think today it is not (only in a flush operation later). Right now I use the client side timestamp (millies), but got already collisions. Bob
