Download the PHP package pmatseykanets/laravel-sql-migrations without Composer

laravel-sql-migrations

Write your Laravel migrations in plain SQL.

If you find this package usefull, please consider bying me a coffee.

Contents

• Why
• Installation
• Usage
  • Make SQL Migrations
  • Run SQL Migrations
• Example Projects
• Changelog
• Contributing
• Credits
• License

Why

Don't get me wrong, the Laravel's SchemaBuilder is absolutely great and you can get a lot of millage out of it.

But there are cases when it's just standing in the way. Below are just a few examples where SchemaBuilder falls short.

Using additional / richer data types

I.e. if you're using PostgreSQL and you want to use a case insensitive data type for string/text data you may consider CITEXT. This means that we have to resort to a hack like this

instead of just

Of course there are plenty of other data types (i.e. Range or Text Search data types in PostgreSQL) that might be very useful but SchemaBuilder is unaware of and never will be.

Managing stored functions, procedures and triggers

This is a big one, especially if you're still using reverse (down()) migrations. This means that you need to cram both new and old source code of a function/procedure/trigger in up() and down() methods of your migration file and keep them in string variables which doesn't help with readability/maintainability.

Even with heredoc / nowdoc syntax in php it's still gross.

Taking advantage of IF [NOT] EXISTS and alike

There is a multitude of important and useful SQL standard compliant and vendor specific clauses in DDL statements that can make your life so much easier. One of the well known and frequently used ones is IF [NOT] EXISTS.

Instead of letting ShemaBuilder doing a separate query(ies) to information_schema

you can just write it natively in one statement

Using additional options when creating indexes

Some databases (i.e. PostgreSQL) allow you to (re)create indexes concurrently without locking your table.

You may need to create a specific type of index instead of a default btree

Or create a partial/functional index

Taking advantage of database native procedural code (i.e. PL/pgSQL)

When using PostgreSQL you can use an anonymous PL/pgSQL code block if you need to. I.e. dynamically (without knowing the database name ahead of time) set search_path if you want to install all extensions in a dedicated schema instead of polluting public.

The .up.sql migration could look like:

and the reverse .down.sql:

Installation

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:

Usage

Make SQL migrations

The most convenient way of creating SQL migrations is to use artisan make:migration with --sql option

which will produce three files

I know, it bloats migrations directory with additional files but this approach allows you to mix and match traditional and plain SQL migrations easily. If it's any consolation if you don't use reverse (down) migrations you can just delete `.down.sql` file(s).*

Note: if you're creating files manually make sure that:

1. The base php migration class extends SqlMigration class and doesn't contain up() and down() methods, unless you mean to override the default behavior.
2. The filename (without extension) of .up.sql and .down.sql files matches exactly (including the timestamp part) the filename of the base php migration.

At this point you can forget about 2018_06_15_000000_create_users_table.php unless you want to configure or override behavior of this particular migration.

SqlMigration extends the built-in Migration so you can fine tune your migration in the same way

Now go ahead open up *.sql files and write your migration code.

I.e. 2018_06_15_000000_create_users_table.up.sql might look along the lines of

and 2018_06_15_000000_create_users_table.down.sql

You can also pass --sql option to make:model artisan command to instruct it to create plain SQL migrations for your newly created model.

Run SQL migrations

Proceed as usual using migrate, migrate:rollback and other built-in commands.

Example Projects

You can find bare Laravel 5.6 projects with default SQL migrations here:

• PostgreSQL
• MySQL

Changelog

Please see CHANGELOG for more information about what has changed recently.

Contributing

Please see CONTRIBUTING for details.

Credits

• Peter Matseykanets
• All Contributors

License

The MIT License (MIT). Please see License File for more information.