4 ms·
I wrote[0] about a method I've used with success in the past. Essentially you use the previous version's hash as the name for the next version. The benefit is t
by clord 10y ago
I wrote[0] about a method I've used with success in the past. Essentially you use the previous version's hash as the name for the next version. The benefit is that merging the work of multiple developers is easier. I ran the process manually when I did it and would love to hear if someone writes a script that makes the process easier.
[0]: https://medium.com/@clord/for-migration-of-schemas-use-version-hash-instead-of-numbers-b57406216a1c https://medium.com/@clord/for-migration-of-schemas-use-versi...
- webmaven 10y agoSo, your data versions form a DAG, sort of like Git commits?
- peclink 10y agoWhat a great idea, thanks for sharing! BTW, why using shell scripts to write migrations is so unpopular? We have lots of language/framework specific solutions or some «language agnostic» tools using plain SQL, both ways are rather limiting.
- ComputerGuru 10y agoSo if you release version 1.0 with hash x, then release version 1.1 with hash y, and then release version 1.0.1 with hash z, 1.0.1 == 1.1?
- clord 10y agoFor branching schemas, yes it gets complicated. But at least you get a nice conflict while merging the branches (at the right place) These conflicts help guide a rewrite of the schema history into something consistent. That's part of it: when a merge happens, you basically have to create a new migration that does the merge too. and if you never merge the forks, there is no problem. they likely won't share a production database anyway, right?
- setheron 10y agoIt's like a block chain!