Custom Cassandra migrations for Lagom itself not possible

We want to migrate the Lagom tables by ourself and not rely on these two settings but set them to false:

cassandra-snapshot-store {
  keyspace-autocreate = false
  tables-autocreate = false
}

This does work for tables-autocreate = false almost all components but not the KafkaTopicProducers which are eagerly started in LagomKafkaComponents via new ScaladslRegisterTopicProducers and that accesses the snapshot store. Also I could not manage to set keyspace-autocreate = false in general.

Expected behavior

I want to decouple C* migrations from the Lagom and run the migrations on my own. This is required for production system upgrades when some of the Lagom tables change.

My workaround is the following:

For Dev/Test I keep keyspace-autocreate = true and tables-autocreate = true and never run migrations for Lagom locally. I don’t like this because I can never test that my migrations are working before I deploy to a preprod environment. Ideally we can somehow hook into the “init” callback from akka-persistence where Lagom creates it’s own tables.

For production we set keyspace-autocreate = false and tables-autocreate = false and manage migrations by oureself by running them after the deployment. Of course this requires Lagom code to be compatible with new and old versions which is usually the case.

Lagom Version (1.2.x / 1.3.x / etc)

1.4.

API (Scala / Java / Neither / Both)

Scala

[fkoehler]

One possible workaround would be to make your service implementation’s constructor depend on the component that needs to run first. This will ensure the right ordering, though if the dependency executes asynchronously you would also need to block on it to prevent initialization from proceeding.

I followed your advice and this is how I was able to solve the problem (in dev mode, using the right init order for the traits and making the migrations blocking)

[TimMoore]

@fkoehler I would not recommend performing migrations from the ApplicationLoader, because in a multi-node cluster it will run on each node. Cassandra schema modifications are not concurrency safe, so you should run migrations in production using a separate process decoupled from your services.

It’s a fair point about having more control over the initialization process, however.