Database versioning is one of those things that you need to think about before development start to make things go smoothly, but when the hell does things go smoothly these days? Most of the time when you join a company with a development team, shits have almost hit the roof (sometimes its already spilling over, you just have to keep more pressure on the lid).

This is the story of IyachtuXvim, Senior Developer of Strife, Hatred and Tyranny, who have just joined an ancient organization, as old as he is, thinking this organization might be the “one”. If this organization has survived all these years maybe the management or development team have ironed out most of the kinks and shit.

Little did he know that he have made a huge mistake.

As IyachtuXvim sitting in his cubicle watching videos of cats doing silly things, surrounded by 15 other junior developers in their cubicles spewing out codew like a chinese iPhone factory, his reporting officer approaches,

Reporting Officer: “Yo Iyachtuxvim! We need to keep track of changes made to the system’s database both mysql and Oracle”.

IX: “Well, how do you guys keep track of it now?”

RO: “Right now, the developers are developing on their local using XAMPP and their local DB. When they make a change to the DB, they email the application manager with the SQL script of the changes (create, alters, etc)”

IyachtuXvim have already tested a small part of the system and the framework in which its built on. All the tools that comes with the framework does not work because the development style does not adhere to the framework’s guidelines. So if he tries to use the CLI tools that comes with the framework, there is so much error that he can almost hear the whisper of Cthulhu himself saying at the back of his mind, “No way, man, that shit ain’t gonna run”. Using the framework’s internal tools to seed or extract the schema and SQLs is out of the question.

IX: “Ok, I can sort that out. We can use an ORM called Doctrine, it has a tool called Doctrine Migration but require the developers to write scripts for the DB changes.”

RO: “Should be ok. But we need to come out with steps on how to get the developers to use it.”

IX: “I’m on it.”

IyachtuXvim went into a trance to write down the steps on how these migrations would work and how it should be implemented by the developers.

The developer will create the migration script with the following command (for mysql/oracle depends on the configuration file)

After the file have been created, modify it to reflect the changes that developer want to make (create table, alter, etc).

After the script is finished, the developer can execute a dry run and see how it goes.

Now the developer have a script that can create, alter and execute SQLs on both MySQL and Oracle. The tool is ready, now to explain to other team who might or might not be involve in the process, with a flow chart of sorts.

IyachtuXvim dreams of automation but it is a scary area because none of the developers are experienced with it, enthusiastic about it or too keen to explore it (signs of enthusiasm will usually gets you in trouble). For IyachtuXvim this is like a foot in the door towards automation.

When the time comes to implement, new “urgent” features plagued the developers. No support from project managers, application manager still oppose the idea of these scripts, arguing whats wrong with the old way of the developer emailing SQLs to him to implement. With no support and backing, the process melts away into oblivion. Forever crushing the dream of automation.

Disheartened, IyachtuXvim went back to watch amusing cats. When the time arrived for slumber, little did he know that the future holds more adventures with the likes of Databus and FlexViews.

And this story shall also be told.