You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of the statements executed will either be LWTs (for lock etc) or schema changes, neither of which use client side timestamps. Are there other statements you think will benefit from this?
@chbatey: Yes. Sometimes, in addition to DDL schema changes, you may want make DML changes e.g. to insert / update "provisioned" data - as distinct from data generated by the running of your application - and I can imagine a scenario where one older CQL file performs action X on a row, and a later CQL file performs action Y on the same row, and we would want action Y to be the "last write" that persists.
This is perhaps relatively unlikely, but given that cqlmigrate is designed to operate from a single client, it feels like a relatively simple change that may save some pain and is certainly not going to do any harm.
Although #29 is still needed for DDL changes, I believe we can and should ensure greater robustness of DML changes by using client-side timestamps (as described in http://www.datastax.com/dev/blog/java-driver-2-1-2-native-protocol-v3) for the CQL statements invoked by cqlmigrate.
Any thoughts / counter-opinions? If not, I'll raise a PR to cover this.
The text was updated successfully, but these errors were encountered: