Recently I’ve found a few interesting tools that help generate Laravel migrations automatically from your already existing database schema. In theory it looks very cool, but we decided to test them – I asked a colleague to actually try them all out with real demo-projects. How do they generate filenames and field types? Additional rules? Foreign keys? Do they actually work? Let’s take a look.
Presenting to you… contestants!
Let’s start with the introduction of the tools:
- Laravel Migration Exporter for Sequel Pro – A bundle for Sequel Pro that lets you generate Laravel migration files from existing tables. Written in PHP language.
- Xethron Laravel Migrations Generator – Laravel artisan-command tool, available as Laravel package
- MySQL Workbench Export Laravel 5 Migrations Plugin – plugin for a popular software MySQL Workbench, written in Python language
Notice: After testing, it appears that Workbench plugin is an almost identical clone of Sequel Pro plugin, just written in Python language, so we didn’t review it. In reality, we have two contestants – Sequel Pro Bundle and Laravel Package.
As a testing project, we decided to take our own Larancer – freelance management project which has a dozen of tables, foreign keys and various field types.
Our test method was simple:
- Run migration files on fresh DB
- Use the tool to generate migrations from DB
- Run new migration files without any changes – do they work?
- Analyze the differences between previous migrations and new generated ones
Also, while testing, we tried to check these things:
- Correct field types assigned
- Nullable assigned correctly
- Timestamps work well
- Foreign keys work well
- Decimal fields work well
Experience with Sequel Pro bundle
Here’s how it works:
And the result of that operation is this list of files:
Looks good so far, right? Ok, let’s try to run the migrations!
Unfortunately, fail 🙁
The problem and the reason is the order of foreign keys created in the wrong order. Basically, after generating the migrations, you have to manually copy-paste foreign keys in correct files, and then it works well.
Also, we’ve found these differences in generated migrations, compared to the original:
- integer()->unsigned() becomes unsignedInteger()
- onUpdate()/onDelete() foreign keys receive RESTRICT mode if no mode provided in original migrations
- Indexes are assigned names which didn’t exist in original. Also indexes are created separately with separate code lines and not within the same field creation code line
- All string/text columns get length parameter, even if it’s a default one
All of those actually are not bad things, just differences and I guess it’s normal.
Now, let’s look at the other contestant.
Experience with Xethron Laravel Package
Here are a few screenshots of Laravel package to generate migrations. We run the command aaaand..
Ok, some questions, let’s proceed.
And finally, we have the result. Fingers crossed…
Ok, migrations generated successfully. First win. Now let’s try to run them:
Success! No, seriously, guys – it worked!
Now, what else we’ve noticed about this package:
- There is a functionality to ignore some tables if you want
- There’s no way (or we didn’t find) to specify the location of the migrations so it stores everything in the same /database/migrations folder
- Foreign key migrations are put in separate files after all the tables migrations
- As the Sequel Pro bundle above, the package adds RESTRICT on foreign keys and generates names for indexes which didn’t exist in the original migrations
Again, those are minor things that you could even call features of the package. But in general, this one is a better option.
So, the final ceremony.
Winner of the battle: XETHRON MIGRATIONS GENERATOR!
But you can still also use a runner-up Sequel Pro bundle, with some manual tweaks it will do the job.
Have fun generating migrations! If you have any personal experience with these tools or similar tasks, shout in the comments.