Support protocol v3 #46
Conversation
|
According to the docs the driver should downgrade the protocol version to match the server:
Did that not work in your case? Would the change to avoid using |
cassandra_migrate/cli.py
Outdated
| @@ -70,6 +70,8 @@ def main(): | |||
| migrations are run against. This option must be used in | |||
| conjuction with the -k option. This option is ignored | |||
| unless the -s option is provided.""") | |||
| parser.add_argument('-v', '--protocol-version', type=int, default=None, | |||
There was a problem hiding this comment.
Can we add a choices argument here matching the enumeration in ProtocolVersion.SUPPORTED_VERSIONS (docs)
There was a problem hiding this comment.
OK, I will hardcode versions 1, 2, 3, 4, 5 instead of passing ProtocolVersion.SUPPORTED_VERSIONS to choices, to avoid potential import errors and to keep it separate from how ProtocolVersion might work internally in the future
I haven't marked this conversation as resolved as I'm not 100% sure about the range solution. If you like it please mark it as resolved :). Let me know otherwise
It did automatically downgrade version when I was testing locally with Docker, but once I pointed the migrations to my development Cassandras in the cloud, it failed to do so. I guess there is some variation on behaviour depending on the version |
That's unfortunate, but not really unexpected; I've seen similar issues pretty much every time when running Otherwise, everything looks good, I'll just do some quick testing and get it merged soon. Thank you! |
Allow a Cassandra
protocol_versionto be passed in as an argument in the CLI and use that when creating aCluster. If no protocol is passed in, the default, existing behaviour with continue to happen.Also, replace
toTimestampwithdateofwhen inserting the DB migration version fi the cluster is using protocol version 3, sincetoTimestampwas introduced in version 4