Open magro opened 10 years ago
Are you sure this is still relevant as the DataStax driver waits for schema agreements?
I thought that in a continous deployment scenario when multiple app servers are started simultaneously the lock table might be useful, so that only one app server instance runs migrations - to prevent race conditions.
This is why you wrote https://github.com/inoio/sbt-pillar-plugin/. In a continous deployment scenario one will run the migrations not in the app server but separately with the SBT task.
Of course if one does not use the plugin the requested feature would make sense but we have no user right now for it. Then pillar would need to implement this with lightweight transactions (paxos) due to the eventual consistent nature of C*
Right, in our case there currently no need for it, but IMHO this would still be a useful addition - that's why I left it open. Perhaps s.o. is looking for cool things to code and stumbles over this issue :-)
When running migrations in parallel (e.g. from integration tests running in parallel or parallel app deployments) there might occur conflicts, because the same migration is run from different clients. The error might look like this:
To prevent this a separate migrations_lock table should/could be used, where a lock is created for the time migrations are performed (liquibase has this for example).