Migration tool–the one that do some updates in bulk, is one of the most important tool/library that developers use to sync up across their peers and server’s current database conditions. Having one is as important as defining your database design on SQL.

While many lib support migration, they mostly either endemic to specific framework or really hard to integrate. So many people may reimplement the migration to that specific framework, thus, the endemic situation is created.

How Other Frameworks Did It?

I’ll explain how other frameworks did it, well, from my perspective. Learning from other has always one of my big influencial of how I do things, creating Ilgar is one of them. I’ll explain from the one that I’ve used so far, so not all frameworks will be explained here.

CodeIgniter 3

Codeigniter–or CI, is one of the most used frameworks that people use, at least on my surroundings when they talk in PHP. CI has it own migration ecosystem and well, I can’t say I like it, but it was the first time I’d learned a lot using the migration tool to sync up many things, database table, uploaded assets, and database rows.

Migration on CI looks quite simple, but actually quite powerful. Migration starts by manually extending the migration class of CI and implement their up and down function to fill in the migration instructuction. Then, as stated by the manual, you have to edit the migration.php on config folder by updating the migration_version to current version in this case your front portion of your migration filename.

To apply the migration, you have to call $this->migration->current() programmatically. Well thats how my coworker used to tell me. Then I learned that you can actually make them automatically run by tweaking the migration settings.

So that being said, I have several things that I like and don’t. Start of by something that I liked. It is… quick, straightforward and easy to predict. This will make debugging things faster since I know that it runs sequencially by the timestamp. Oh also, the risk of conflicting with other people’s migration pack is quite rare since you’re using timestamp based for naming the migration file name. But you will still get problem if you have the same class name with other migration.

Continuing, things that I hate with this system. They are… don’t track each migration. This means if your coworker create new migration and you do as well, when merged, you have chances of your some subset of your migration pack wont run on stagging/preview server. Why? Because your migration pack is older than your coworker’s.

Next, creating the migration is… tedious work. You have to copy-paste the template and naming the files with such pattern manually over and over again. This will develop the “I’ll done it in one file” kind of thing which leads to write-only, hard to manage migration files, not the best feeling ever. I just hate how I need to remember the CI_Migration class name over and over again. It doesn’t look pretty nor comply with PSR-4 standards. At least don’t make me rewrite it.

Currenly Ilgar implementation follow this ecosystem, because… well… because that time I haven’t really touched other framework yet.

Laravel

This framework is one of most used too. On my sourrundings, it is the second. In professional, more agile team, I guess it will be the first.

Laravel’s migration is quite intuitive for me. I mean, there’s much more to discover since they have such amazing libs and—I’ll explain later. It starts off with generating the migration file. Yes you heard it right (or am I the only one that shocked on this new normal?). Then all you have to do is open that newly created file and start making new migration on there. To start the migration all you have to do is execute the php artisan migrate command. Yes. That’s it. You can even do a rickroll rollback on there, move between mig—Oh right, I’ll explain this later too.

Oh god, I can barely hold my excitement when I see their documentation of this when starting new project with my friends. There’s so much that I love from this approach. First of all, YOU’RE NOW ABLE TO GENERATE THE FILE, AUTOMATICALLY. Yes, no more right-click, new file, see clock, write the formats, see older migration, select all, copy, move to new file, paste, clean the code, then do your thing there. NO! Those are done in merely one simple, quick, easy to remember command, php artisan make:migration. Yes.

Then, It tracked each migration on the DB, if you don’t have that migration applied, it will. So if your coworker created migration that are newer in their PR, once your PR and your coworker’s PR is merged to master, Laravel will make sure all of the migration is executed properly! YES! No more “Please update the version to newer than PR #xxx” thing.

Also, it’s PSR-4 Compliant! You know what, I REALLY LOVE INTELLISENSE. It helps me a lot by not making stupid, fatal mistake on calling many libs inside the migration ecosystem. This leads to… me, making things more better migration such as don’t use hard-coded ID while deploying assets to uploads folder. Oh wow. Also the most important part, making me not looks stupid when demoing things to other coworker. IntelliSense, we shall date more.

Oh, one of the best features: The Seeders! Man…, if I have camera, I’ll record my scream when I discover such thing exists. Yes, you can now add dummy data AND not contamitating the production database.

Well, to be politically correct, I shall as well share my dislikings to this framework. As I don’t use Laravel as much as other people does, I might nitpicking this one too much. The one that I hate was there’s no built in command to run the migration via HTTP call. This leads to me, should find hosting service that support shell access to the hosting just to run many things. Maintenance, migration, rollbacks, etc. That’s okay tho. I still love this framework.

TypeORM

While this one is from Javascript world, and yet it is in fact ORM lib, not framework, this must be notable enough to discuss, right? Yes!! –and in fact I love it so FRIGGING much!

TypeORM migration is quite intimidating at first, at least to me. I need to re-read the docs several times before finally understanding I need to tweak some settings before it works (my fault for not reading the docs properly ????). First of all, just like Laravel, you need to generate the migration file by executing typeorm migration:create command. Lovely. Then you can do your things before finally apply the migration by executing the command typeorm migration:run. Superb.

Now that I know that’s the industry standard of migration ecosystem, I shall readjust my expectations quite a bit. You know, the generate thing. But man, this one, OBLITERATE the definition of generate, because this library literally able to diff your table schema from your TypeORM model class and your current table situation like… boi… what kind of socery is this ????.

Tough I love how revolutionary is this to me, I can’t lie I have several things that makes me rethink when to use TypeORM on my projects. First, TypeScript support. Not using TypeScript usually means you’re doing it in gangster style. TypeORM do support TypeScript, but when using the CLI command, you have to explicitly define that it need to be runned under ts-node. You know, it adds REALLY LONG command to run things.

ts-node ./node_modules/typeorm/cli.js migration:run

See, how long it is? Ridiculus right? So the workaroudn of this, I usually adds typeorm script to my package.json file to make things simpler.

Other nitpick that I have is… the revolutionary part of this framework is limited to… what your current database software you’re using. I mean, if you run it under MariaDB, it will generate ALTER TABLE SQL based on MariaDB. If you run it on PostgreSQL, it might not work (please correct me if i’m wrong). This is because of the script generate static SQL script instead of generating Js/Ts code that uses their wrapper. So all you have to do is reimplement those script in Js/Ts if you want it to support more database servers.

Replanning The Ilgar

Well, with all of the most influencial migration tool that I’ve learnd so far this has to be have some impact on future of Ilgar, right? The answer is yes.

Ilgar is one of my beloved open source project because of I feel like I grow up with FatFree Framework and now I made one of their helpers! I just love it how now I can contribute to their community as a developer, like, you know, functioning member on society.

So, in the future of Ilgar, I will make it better by implementing things that will be much more simmilar to Laravel and TypeORM. The real reason of this movement is because I feel comforted with how those frameworks done it. I mean, I’ve experienced how 3 or more people working on a project, making some changes on database and now one of the PR (Pull Requsest/Merge Request) breaks other PRs because of the migration didn’t run properly. Ugh, I just hate how I have to specifically request them to update the migration version to be newer than those newest merged PR.

The future Ilgar may have a table dedicated to track each migration file. Just to make sure everything have ran properly.

Then, we might create a little CLI tool to generate the migration file to a designated folder. We can add configuration to your current composer.json file but I don’t really know. We’ll see later.

Conclusion

So that’s it. Reinventing the Wheels isn’t always have bad meaning. I learned a lot by learning how other developers did it. Also, yes, developer experience matters.

Ilgar will have new strategy that will defenitely improves the DX of the library. I will try to work at this once I have more time.

Credits:
Featured Image by Keith Luke on Unsplash