Support protocol v3

[josebama]

Allow a Cassandra protocol_version to be passed in as an argument in the CLI and use that when creating a Cluster. If no protocol is passed in, the default, existing behaviour with continue to happen.

Also, replace toTimestamp with dateof when inserting the DB migration version fi the cluster is using protocol version 3, since toTimestamp was introduced in version 4

[danielkza]

According to the docs the driver should downgrade the protocol version to match the server:

If not set in the constructor, the driver will automatically downgrade version based on a negotiation with the server, but it is most efficient to set this to the maximum supported by your version of Cassandra. Setting this will also prevent conflicting versions negotiated if your cluster is upgraded.

Did that not work in your case? Would the change to avoid using toTimestamp be sufficient?

[danielkza]

Can we add a choices argument here matching the enumeration in ProtocolVersion.SUPPORTED_VERSIONS (docs)

[josebama]

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

[josebama]

Did that not work in your case? Would the change to avoid using toTimestamp be sufficient?

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

[danielkza]

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 cqlsh from outside the Cassandra machines.

---

Otherwise, everything looks good, I'll just do some quick testing and get it merged soon. Thank you!

[Mateus-Goes]

🔒 Novo check de segurança na Cobli: SAST + secret scanning

Este PR passou a rodar um gate automático de segurança (Opengrep + gitleaks) via GitHub Actions, agora ativo em todos os repositórios da org.

• Modo consultivo (advisory): por enquanto ele só comenta os achados — não bloqueia o merge. Em ~1 semana passará a bloquear apenas achados críticos novos (severidade ERROR) introduzidos no próprio PR.
• Se aparecer um check "Expected"/pendente segurando o merge, ele se resolve no próximo push deste PR (ou ao rebasear, caso esteja com conflito).
• Nenhuma ação necessária da sua parte por enquanto.

Dúvidas? Fale com o time Kali no #help-tech-kali-dis.