smartcat-labs
No way of running skipped migrations
To reproduce:
Apply schema updates with version #1, #2, #4 Apply schema update #3
Expected: Schema update #3 applied
Observed: #3 not applied as version is already at #4
This behavior is inconsistent with other migration tools such as dbdeploy or rails active record migrations
Hi @dalvizu, The migration process is designed so that it doesn't "fill" the missing versions but rather skips all versions prior to the current one. This approach simplifies both this codebase but also migration code. The implementation you are talking about could abstract upgrade and downgrade implementation for each migration where we can always "roll back" a version (much like up and down in rails activerecord migrations). I'm ok with going into that direction but can you explain the situation how could you end up with 1, 2, 4 versions applied and version 3 skipped?
Hi @mgobec
I'm using this library to develop a DSL based migration framework. Our dev teams use both dbdeploy (an ancient java project) and (on a much smaller scale) rails active record to do migrations and use a feature branching similar to git-flow. We're looking to use the same for cassandra.
This has some overlap with #34 so I wasn't sure if I should split them apart - when devs are working on feature branches they will run into conflict if they use the integer version incrementing by one -- dev works on branch A and uses (current version+1) - so does dev on branch B, and then one of their updates will disappear during merge.
One way around this is to have some strategy on picking integers to guarantee uniqueness: 20160301 is somewhat unique. But if someone runs a migration with 20160302 before you run yours, yours will not be applied
Great to hear that you guys are building something like that and I'm really happy that you are building from this framework. How its currently implemented it served all our use cases so far but I'm open for suggestions. The dev situation needs to be solved by a merge process. What can be done to help out is making the schema version an version 1 UUID which each user generates when they create a new migration but also reference the last one they are upgrading from. No two users will be able to generate the same UUID and the logical order will be maintained. I still think that this is too much work for something that should be solved somewhere else (git merge process). The out of order upgrades can be tricky but I'm ok with supporting that too by implementing up-down mechanism.
I'm working on a PR to address this and #34 - my plan is to keep all contracts in place and then allow a place to extend it -- I want to be able to version mine as '20180514[...]' which doesn't work with integer. Similar approach could work with UUID - I like using a date-based string vs UUID because it obeys the Comparable contract.