Ever wondered how the croupiers do that shuffle when they separate the card deck in two and just mix both piles into one? I’ve tried that multiple times and the cards just flew everywhere 😞. But now imagine that you could do that shuffling with your data and structure migrations, aligning them to run in the order they should…That would be a cool thing! While your application starts getting bigger and bigger, probably so does your migration folder and with that you’ll probably need to move some data around different tables, or even change such data because your structure changed as well. When do you run your migrations? First the data migrations and then the structure migrations or the other way around? With any of those approaches some errors are prone to happen: On the first approach (data → structure) what would you do, if the field that you need isn’t created yet (because the structure migration hasn’t run)? On the second approach (structure → data) what would you do, if the field that you want to populate needs data from another field that is deleted on the structure migration? Let me show you an example: Let’s say you have a model with a boolean attribute named that represents the deleted ; Post :deleted Posts After some time, and some deleted , you are asked to instead of just knowing that a was deleted we also need to know when the was deleted. So you create the field that will contain the date it was deleted; Posts Post Post :deleted_at Now you create the data migration that searches all the deleted and timestamps the field. So far so good; Posts :deleted_at After that is done you can safely remove the old and obsolete field. :deleted So with this example we have 2 structural migrations (creating the field and deleting the field) and 1 data migration (populating the field). It’s all peachy and dandy until you run your migrations because when you finish running the structural ones you will not have a field to query the that were deleted. :deleted_at :deleted :deleted_at :deleted Posts With this in mind let me introduce you to , the gem that will make that pain go away. Systematize How does it work? Just add it to your Gemfile: #Gemfilegem 'systematize', '~> 0.0.1' or install it via bundler bundle install 'systematize' Surprise, surprise you have some shinny new tasks! $> bundle exec rake -Trake systematize:migrate # Migrate the databaserake systematize:rollback # Rollback the database (options: STEP=x, VERBOSE=false)rake systematize:rollback_all # Rollback all the database With this your migrations will be re-arranged and they will run in the timespan order to make sure that all goes peachy keen! It’s not all fun and games you know? For this to go smoothly as it should you just need to respect some rules: The migrations need to be in the correct folder, for structural migrations it should be and the data migrations should live in . Like this: db/migrate db/data app | |-db |-data |-migrate The migrations need to follow the convention Rails YYYYMMDDHHMMSS_create_products.rb Time to shine Now if you need to migrate the you just need to run: database bundle exec rake systematize:migrate Needing to rollback the previous migration? No problem. bundle exec rake systematize:rollback Need to rollback 2/3/4 migrations? I got you. bundle exec rake systematize:rollback STEP=2 Made a mess so big you need to start fresh? Do it. (the migrations need to be reversible 😅) bundle exec rake systematize:rollback_all Don’t forget to smash that 💚 button and if you have anything to say, just drop like it’s hot ! @RicBrazao
