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 Post model with a boolean attribute named :deleted that represents the deleted Posts ;

model with a boolean attribute named that represents the deleted ; After some time, and some deleted Posts , you are asked to instead of just knowing that a Post was deleted we also need to know when the Post was deleted. So you create the :deleted_at field that will contain the date it was 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; Now you create the data migration that searches all the deleted Posts and timestamps the :deleted_at field. So far so good;

and timestamps the field. So far so good; After that is done you can safely remove the old and obsolete :deleted field.

So with this example we have 2 structural migrations (creating the :deleted_at field and deleting the :deleted field) and 1 data migration (populating the :deleted_at 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 :deleted field to query the Posts that were deleted.

With this in mind let me introduce you to Systematize, the gem that will make that pain go away.