search

laravel / ideas

Issues board used for Laravel internals discussions.
939 stars 28 forks source link

[Proposal] SQL Migrations #1123

Open barbu110 opened 6 years ago

barbu110 commented 6 years ago

Hi!

Something I turned out to need during my development process was SQL migrations. We have to admit that some SQL is easier to write in plain than using any ORM.

A quick workaround to this was running artisan make:migration then populate it with:

DB::unprepared(File::get('...'));

I named my SQL file with the exact name given by the Artisan command. So how about adding an option to make:migration? Something like --make-sql?

No rollback supported

I thought of this, since we cannot split a SQL file in multiple blocks. To be honest, I am not always adding something to the down method in the migrations. So next to --make-sql, an option --enable-rollback could be added to generate yyyy_mm_dd_migration_name.sql and yyyy_mm_dd_migration_name.down.sql.

What do you think?

mfn commented 6 years ago

My understanding is a) you already showed a possible solution using unprepared which can do exactly what you need and b) adds just more complexity for very special cases.

I've been using unprepared for exact this reason for a long time and it works very well IMHO. Also, there are times when I use regular blueprint (because convenience) together with unprepared for special stuff(triggers, etc.) and it works well 👍

pmatseykanets commented 6 years ago

Although unprepared() works fine, maintaining migration scripts in variables (which is inevitable with this approach) even using heredoc especially when you have plenty of stored routines (functions, procedures, triggers etc) is a pain.

For this exact reason I've created this experimental package that I use in my projects https://github.com/pmatseykanets/laravel-sql-migrations that abstracts this away to some degree and allows mixing plain SQL and ordinary migrations.

All in all having a native framework support for plain SQL migrations can be a great thing.