Migrations and throwing your plans out the window

My-Grations: A reflection on my week

09-12-20 

Written from a Sublime Text Editor

A data migration is a way to update your entire database schema quickly and safely, I spent three days this week doing this quickly and safely. I currently adminstrate, update, manage, maintain, if you can do it with software I do it, to two different systems. One of these systems is running code that is 10 years old, the other is more up to date. This week I had to write my first migration for the one running Django 1.4.XX, this may not be recommended.

Migrations are a great and safe way to change your data, they allow you to test your changes locally, then move them to a demo environment, then move them to production all while testing along the way, and they scare me to death. They amount to changing a lot of data with code, in my case it wasn't much data, but tracking down what needed to be changed was difficult, since I didn't know how the tables were connected. A very capable developer helped me to figure this out and ultimately test all of this, but you get a great awakening of how little you know when you have to automatically change models at once, since you may miss something that needed to be updated as well.

The great thing about migrations are you can write the downgrade, rollback, of a migration while you write the upgrade, which is a great way to rollback incase you have made some mistakes. I've seen a surprising amount of migrations that were written with no downgrade and one day I hope to meet this brave cowboys, so I can make sure I never go near them again. I do not know how anyone could write a change without a way of rolling it back. According to Django's docs on migrations they are like version control for schema changes, but not writing a downgrade seems to throw this idea out the window.

I had a plan to write some jasmine test this week, but this migration kind of laughed at the thought of writing test and threw them out the window, since one was for active clients and the test are for code waiting to be implemented. It's like the saying, "If you want to hear God laugh tell him your plans", this was compounded with I have been trying to write said test for a while and the migrations were new in a version of Python I rarely touch.

The big take away from this week was don't be so afraid to make sweeping changes, read the code to find where the proper foreign keys are, test, test, test, and if a system requires migrations to get something working you may need to rethink how you are working in the system, since it is time consuming. I'm about to start writing complex migrations just to get the practice in, I don't like being so intimidated by changes to software, not to mention the questions of self worth, but it's just something you have to get use too, also probably read or if you've already read it reread The Phoenix Project.