Download the PHP package ikto/pg-migration-directories without Composer

On this page you can find all versions of the php package ikto/pg-migration-directories. 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?

Example code of ikto/pg-migration-directories

Informations about the package pg-migration-directories

Pg Migration Directories

Short description

This library is inspired by DBIx::Migration::Directories perl module. Main goal is providing tiny platform to run database migrations on PostgreSQL databases. This library cannot work out of the box though. To make it work need to implement database connection adapter. Also, it is possible to alter the behaviour of this tool.

Features

Requirements (environment)

How it works: high level description

In short the workflow can be illustration as several steps.

Step 1. Discovering available migrations

At first the tool gets a list of available migrations. The way how exactly how does it happen can be any. The exact way of discovering and loading migrations is "described" in migrations discovery implementation. This package contains the simplest one: SqlFilesDiscovery.

SqlFilesDiscovery

For this discovery each migration is a directory which contains a bunch of SQL files. Migrations directory should have the following layout:

At the top level there are directories named as db schema which we manage: in this example we manage the schema named DBSCHEMANAME. There is a Pg directory inside of each. On the next level there is a set of directories named using the following pattern: [from_version]-[to_version]. Each of these directories represent the single migration. In other words each directory contains instructions how to update the db schema from one version to another (it may be upgrade or downgrade). If directory name contains only one version number - it will be considered as 0-[version]. Zero version number means that db schema is not installed yet. Each version-named directory should contain a set of SQL files. The naming of SQL files is arbitrary, but please note, when performing migration SQL files will be sorted alphabetically.

Step 2. Building migration path

This step is pretty simple. The existing db schema already has some version (zero if it is not installed yet). User/developer provides the version to migrate to (desired version). By having a list discovered migrations, current and desired versions the migration path builder constructs the list of exact migrations which need to be applied to reach the desired version. Usually there is no need to alter this behaviour, but it is possible though.

Step 3. Applying migrations

Even simpler step. One thing left: apply each of migration to db. From step 2 we have a list, so here we just iterate over the list and apply each migration.

Each migration is applied with processor. The migration discovered by SqlFilesDiscovery will be applied by SqlFilesProcessor. It sorts SQL files alphabetically, loads SQL commands and executed them in order.

Code example

This library does not provide ready-to-use program to apply migrations. The following example shows what the program should do.

Tracking db schema version

To monitor the state of the db the library holds the data about migration inside of db. These table should be created with the first migration which install the db schema.

Usually these tables are stored under the public schema. But you are able to store them in another, just don't forget to change the third constructor argument when you're creating managed db object (or corresponding parameter for StateManager).

Also, it is possible to store db schema version somehow differently, but then StateManager needs to be replaced. To replace StateManager the managed db class should be replaced as well.

All versions of pg-migration-directories with dependencies

PHP Build Version
Package Version
Requires php Version >=7.0
symfony/finder Version >=3.4
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 ikto/pg-migration-directories contains the following files

Loading the files please wait ....