locationtech
GEOMESA-3435. mention scylladb in docs
ScyllaDB is a drop in more performant replacement for Cassandra. It works out of the box with GeoMesa just by replacing connection string from Cassandra to ScyllaDB. Lets mention this in docs so people will be aware of such option.
Thanks for adding the docs! I don't think we should replace all mentions of Cassandra with Cassandra/ScyllaDB - how about adding a new scylladb/index.rst file that comes after Cassandra and just says that the Cassandra store is also compatible with ScyllaDB? And if there are any differences (e.g. /etc/scylla/scylla.yaml for config), call them out there.
changes look reasonable to me, but the build is failing. @jnh5y do you have any comments?
@mkorolyov thanks for adding the test containers; it is a huge help to be able to test things over time!
@elahrvivaz The changes look reasonable to me. As soon as we get a green build, I'd say it is good to go. I kicked off the build...
I see some codacy things failed; I don't understand it.
the codacy failure just needed a retry, and the dash failures are b/c i opened some eclipse tickets that are in an "open" unresolved state, so no worries there.
Good evening @elahrvivaz - it looks like this PR might have been abandoned, but it’s a great idea and I’d be happy to pick it up and get it over the line.
Would you prefer that I open a new PR from my own fork, resolving the conflicts in the process?
Good evening @elahrvivaz - it looks like this PR might have been abandoned, but it’s a great idea and I’d be happy to pick it up and get it over the line.
Would you prefer that I open a new PR from my own fork, resolving the conflicts in the process?
@andrii-kysylevskyi that would be great if you wan to push this over the line! I assume a new fork would be required, since you probably can't update this current fork?
we've actually already transitioned to using testcontainers with cassandra, so the test file changes might be easier to make from scratch. maybe just creating a new test class that extends the current one and overrides the container definition would be better (making the container definition extensible in the base class)?
Hi @elahrvivaz and thanks a lot for your quick response! You’re right - I can’t contribute directly to this PR, so I’ll open a new one from my own fork following the approach you suggested (once I’ve completed the remaining setup steps for contributing)
Would it be okay if I add you as a reviewer once I open the PR, since you already have the context on this?