Download the PHP package gridonic/migration-service-provider without Composer

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

FAQ

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.

Example:
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-service-provider

MigrationServiceProvider

Build Status

This is a simple homebrew schema migration system for silex and doctrine.

Install

As usual, just include gridonic/migration-service-provider in your composer.json and register the service.

Key Type Optional Description
migrations.path String, folder path - Where are your migrations?
migrations.register_before_handler Boolean x Should the service run the migrations on each boot?
migrations.migrations_table_name String x The name of the table in the database, where the migration_version is safed. Default schema_version

Enough small talk, I want to write migrations!

Perhaps, this documentation is not complete. So here are some links with more informations:

Running migrations

There are two ways of running migrations

Using the before handler

If you pass a migration.register_before_handler (set to true) when registering the service, then a before handler will be registered for migration to be run. It means that the migration manager will be run for each hit to your application.

You might want to enable this behavior for development mode, but please don't do that in production!

Using the migration:migrate command

If you installed the console service provider right, you can use the migration:migrate command, so your app does not have to run the migrations each time when your web-Application is called.

Writing migrations

A migration consist of a single file, holding a migration class. By design, the migration file must be named something like <version>_<migration_name>Migration.php and located in src/Resources/migrations, and the class <migration_name>Migration. For example, if your migration adds a bar field to the foo table, and is the 5th migration of your schema, you should name your file 05_FooBarMigration.php, and the class would be named FooBarMigration.

In addition to these naming conventions, your migration class must extends Gridonic\Migration\AbstractMigration, which provides a few helping method such as getVersion and default implementations for migration methods.

The migration methods consist of 4 methods, which are called in this order:

schemaUp

You get a Doctrine\DBAL\Schema\Schema instance where you can add, remove or modify the schema of your database.

appUp

After the schemaUp, you can edit the application - you get a Silex\Application instance for that. Here you can modify existing data after you have added a column.

schemaDown

After the appUp, you can modify the schema of your database again. You get a Doctrine\DBAL\Schema\Schema instance which you can use.

appDown

Last but not least, you can work again with a Silex\Application instance. Modify the existing data or something like this.

Migration infos

There's one last method you should know about: getMigrationInfos. This method should return a self-explanatory description of the migration (it is optional though, and you can skip its implementation). If you use Twig, we have built in a migration_infos for twig - perhaps a function just for the developer-mode.

You can then use it with something like that:

Licence

The MigrationServiceProvider is licensed under the MIT license. The original library from is taken from the KnpLabs.


All versions of migration-service-provider with dependencies

PHP Build Version
Package Version
Requires php Version >=5.3.2
silex/silex Version ~1.1
doctrine/dbal Version >=2.1, <=2.4
symfony/finder Version ~2.1
gridonic/console-service-provider Version ~1.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package gridonic/migration-service-provider contains the following files

Loading the files please wait ....