Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add migration lock table #11

Open
magro opened this issue Jun 3, 2014 · 4 comments
Open

Add migration lock table #11

magro opened this issue Jun 3, 2014 · 4 comments

Comments

@magro
Copy link
Contributor

magro commented Jun 3, 2014

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:

com.datastax.driver.core.exceptions.InvalidQueryException: Invalid
column name mycolumn because it conflicts with an existing column

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).

@fkoehler
Copy link
Contributor

Are you sure this is still relevant as the DataStax driver waits for schema agreements?

@magro
Copy link
Contributor Author

magro commented Jul 14, 2014

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.

@fkoehler
Copy link
Contributor

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*

@magro
Copy link
Contributor Author

magro commented Jul 14, 2014

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 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants