I'm working in an environment where rather than deploying changes directly to the clients servers I have to generate a build tarball with a changelist from an SVN revision and send it over to their web team.
The problem is that I'm not allowed anything fancy, only changes to the site assets and raw queries, this means I can't ask the client to run laravel migrations when I need them to make a change to their staging & live databases (and I don't trust migrations enough for live anyway.) I won't have access to the live database directly either.
So what I want to be able to do is capture the raw SQL when a migration is run, from there I can see exactly what's changing and I can tell the client "here's an SQL file of what needs to change, review it an run it when you apply the update."
We have created a laravel package to keep the track of raw SQL migration using package [Laravel raw sql query migration] The migration file is used to keep track of the tables created by Laravel. We use the package to create tables and modify the columns in the database but we also wanted to share the tables across the developers.
The Laravel Framework interacts with databases using raw SQL, the fluent query builder, and the Eloquent ORM. It supports the following four databases. MySQL version 5.6+
The .up.sql migration could look like: You can install the package via composer: If you're using Laravel < 5.5 or if you have package auto-discovery turned off you have to manually register the service provider: // config/app.php 'providers' => [ .. . SqlMigrations \ SqlMigrationsServiceProvider ::class, ],
A migration class contains two methods: up and down. The up method is used to add new tables, columns, or indexes to your database, while the down method should reverse the operations performed by the up method. Within both of these methods, you may use the Laravel schema builder to expressively create and modify tables.
As an alternative solution that doesn't require setting up any event listeners, you can use the --pretend
option when running the command:
php artisan migrate --pretend
This will dump SQL queries that would be run by the migration, but without actually running the migration. It will output on each line the class name of the migration and query being run from that migration, so for a migration that creates a users
table with a unique email
column, you'll get something like this:
CreateUsersTable: create table `users` (`id` int unsigned not null auto_increment primary key, `email` varchar(255) not null, `password` varchar(60) not null, `created_at` timestamp default 0 not null, `updated_at` timestamp default 0 not null) default character set utf8 collate utf8_unicode_ci
CreateUsersTable: alter table `users` add unique users_email_unique(`email`)
This option is present since Laravel 4 up to the newest version of Laravel (which at the time I'm posting this answer is 5.1).
If you add this to the beginning of your Routes.php
file - it will dump all SQL that is run by Laravel:
Event::listen('illuminate.query', function($sql)
{
var_dump($sql);
});
So do that, then run php artisan migrate
- and all the SQL is dumped.
You could then just log the SQL to a file or something instead of doing a var_dump - the possibilities are endless...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With