RF=1 and locking

[Jan-M]

Just from a quick look it seems to me you are not taking the distributed nature of Cassandra into consideration here.

First of all tracking the state in an RF=1 key space makes little sense when you loose a node and basically loose the state of your evolutions.

Second I am unable to quickly spot a line where you lock on the evolution id, I would expect to use at least a lightweight transaction on insert or update before starting to execute the evolution as today a lot of services do not start up on a single node.

[untoldwind]

You are right, this adapter is kind of an MVP in context of a specific project.

As for the the replication factor: Well, yes that should be a configuration parameter. RF=1 is good for development (as you usually only have one node there), in production it should be higher of course ... we adapted it to our needs and cluster size via the opscenter.

Locking is more tricky as there are different ways (and requirements) to implement this in a cluster. I did not wanted to enforce a specific strategy, instead locking is intentionally left open by overriding the "CassandraEndpointConfig.executeWithLock" function.
In our project we configured cassandra via etcd, which can be used for locking as well.
A pure cassandra solution would probably be a CAS operation on a row with expiration.