Download the PHP package byjg/migration without Composer

On this page you can find all versions of the php package byjg/migration. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.


After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package migration

Database Migrations PHP

Opensource ByJG GitHub source GitHub license GitHub release Scrutinizer Code Quality Build Status


This is a simple library written in PHP for database version control. Currently supports Sqlite, MySql, Sql Server and Postgres.

Database Migration can be used as:

Database Migrates uses only SQL commands for versioning your database.

Why pure SQL commands?

The most of the frameworks tend to use programming statements for versioning your database instead of use pure SQL.

There are some advantages to use the native programming language of your framework to maintain the database:

But at the end despite these good features the reality in big projects someone will use the MySQL Workbench to change your database and then spend some hours translating that code for PHP. So, why do not use the feature existing in MySQL Workbench, JetBrains DataGrip and others that provides the SQL Commands necessary to update your database and put directly into the database versioning system?

Because of that this is an agnostic project (independent of framework and Programming Language) and use pure and native SQL commands for migrate your database.


PHP Library

If you want to use only the PHP Library in your project:

Command Line Interface

The command line interface is standalone and does not require you install with your project.

You can install global and create a symbolic lynk

Please visit to get more informations about Migration CLI.

Supported databases:

Database Driver Connection String
Sqlite pdo_sqlite sqlite:///path/to/file
MySql/MariaDb pdo_mysql mysql://username:[email protected]:port/database
Postgres pdo_pgsql pgsql://username:[email protected]:port/database
Sql Server pdo_dblib, pdo_sysbase Linux dblib://username:[email protected]:port/database
Sql Server pdo_sqlsrv Windows sqlsrv://username:[email protected]:port/database

How It Works?

The Database Migration uses PURE SQL to manage the database versioning. In order to get working you need to:

The SQL Scripts

The scripts are divided in three set of scripts:

The directory scripts is :

Multi Development environment

If you work with multiple developers and multiple branches it is to difficult to determine what is the next number.

In that case you have the suffix "-dev" after the version number.

See the scenario:

In both case the developers will create a file called 43-dev.sql. Both developers will migrate UP and DOWN with no problem and your local version will be 43.

But developer 1 merged your changes and created a final version 43.sql (git mv 43-dev.sql 43.sql). If the developer 2 update your local branch he will have a file 43.sql (from dev 1) and your file 43-dev.sql. If he is try to migrate UP or DOWN the migration script will down and alert him there a TWO versions 43. In that case, developer 2 will have to update your file do 44-dev.sql and continue to work until merge your changes and generate a final version.

Using the PHP API and Integrate it into your projects.

The basic usage is

See an example:

The Migration object controls the database version.

Creating a version control in your project:

Getting the current version

Add Callback to control the progress

Getting the Db Driver instance

To use it, please visit:

Tips on writing SQL migrations for Postgres

Rely on explicit transactions

It is generally desirable to wrap migration scripts inside a BEGIN; ... COMMIT; block. This way, if any of the inner statements fail, none of them are committed and the database does not end up in an inconsistent state.

Mind that in case of a failure byjg/migration will always mark the migration as partial and warn you when you attempt to run it again. The difference is that with explicit transactions you know that the database cannot be in an inconsistent state after an unexpected failure.

On creating triggers and SQL functions

Since the PDO database abstraction layer cannot run batches of SQL statements, when byjg/migration reads a migration file it has to split up the whole contents of the SQL file at the semicolons, and run the statements one by one. However, there is one kind of statement that can have multiple semicolons in-between its body: functions.

In order to be able to parse functions correctly, byjg/migration 2.1.0 started splitting migration files at the semicolon + EOL sequence instead of just the semicolon. This way, if you append an empty comment after every inner semicolon of a function definition byjg/migration will be able to parse it.

Unfortunately, if you forget to add any of these comments the library will split the CREATE FUNCTION statement in multiple parts and the migration will fail.

Avoid the colon character (:)

Since PDO uses the colon character to prefix named parameters in prepared statements, its use will trip it up in other contexts.

For instance, PostgreSQL statements can use :: to cast values between types. On the other hand PDO will read this as an invalid named parameter in an invalid context and fail when it tries to run it.

The only way to fix this inconsistency is avoiding colons altogether (in this case, PostgreSQL also has an alternative syntax: CAST(value AS type)).

Use an SQL editor

Finally, writing manual SQL migrations can be tiresome, but it is significantly easier if you use an editor capable of understanding the SQL syntax, providing autocomplete, introspecting your current database schema and/or autoformatting your code.

Handling different migration inside one schema

If you need to create different migration scripts and version inside the same schema it is possible but is too risky and I do not recommend at all.

To do this, you need to create different "migration tables" by passing the parameter to the constructor.

For security reasons, this feature is not available at command line, but you can use the environment variable MIGRATION_VERSION to store the name.

We really recommend do not use this feature. The recommendation is one migration for one schema.

Running Unit tests

Basic unit tests can be running by:

Running database tests

Run integration tests require you to have the databases up and running. We provided a basic docker-compose.yml and you can use to start the databases for test.

Running the databases

Run the tests

Optionally you can set the host and password used by the unit tests

Related Projects

Open source ByJG

All versions of migration with dependencies

PHP Build Version
Package Version
Requires byjg/anydataset-db Version 4.1.*
ext-pdo Version *

The package byjg/migration contains the following files

Loading the files please wait ....