Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use client-side timestamps #32

Open
oliverlockwood opened this issue Aug 15, 2016 · 3 comments
Open

Use client-side timestamps #32

oliverlockwood opened this issue Aug 15, 2016 · 3 comments

Comments

@oliverlockwood
Copy link
Contributor

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.

@oliverlockwood
Copy link
Contributor Author

@vasiuadriana @sebbonnet ?

@chbatey
Copy link
Contributor

chbatey commented Aug 23, 2016

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?

@oliverlockwood
Copy link
Contributor Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants