Achilles prevents upgrading from Cassandra 2.x to Cassandra 3 cluster without big bang rewriting all the code.

[bric3]

With the following preconditions

• Existing 2.1.x cassandra cluster
• Achilles 3.2.x / Cassandra driver 2.1.x
• Multiple existing entities

If we want to upgrade the cluster to cassandra 3.x, we have to use the driver 3.x as well. However the first version that is compatible with version is Achilles 4.x. However this version marks the beginning of code generated PersistenceManager, and this is the problem : the code is not generated if the current code doesn't compile already which is almost impossible to get because almost every Achilles symbol of version 3.x is not available.

So new generated symbols are not generated, which makes it even harder to get the code right and thus compiling. Spring injection fails, etc.

TDD and incremental changes are impossible when migrating from Achilles 3.x to 4.x, which makes migration even less safe or way harder to roll out.

If migration is that hard, it may even be worth it to use the driver itself, this is sad for Achilles.

Possible solutions on Achilles side

• Either upgrade Achilles 3.x to driver 3.x
• Or add back a non generated persistence manager as a backward compatible way to upgrade.

[doanduyhai]

Why don't you

1. Upgrade client code to use Achilles 5.1.0 with code generation, still keep Cassandra in production to version 2.1.x
2. Then migrate Cassandra in production to 3.0.x

?

[bric3]

Upgrade client code to use Achilles 5.1.0 with code generation

This code upgrade of the client is the main issue of this ticket.

If I'd like to rewrite the code, I need the Achilles generated APIs, but they are not available since the module does not compile successfully. And because these APIs are not generated I cannot make use them to make the module compile successfully.

The only option at the moment is to rewrite all the client code by knowing exactly what Achilles could have generated before the module could be compiled successfully.