Initial commit: apps.supersam24.ru
This commit is contained in:
root committed
commit
e955e1da36
6566 files changed
+1271095
No files matched your search
+339
@@ -0,0 +1,339 @@
|
||||
.. index::
|
||||
single: Commands
|
||||
|
||||
Commands
|
||||
########
|
||||
|
||||
Phinx is run using a number of commands.
|
||||
|
||||
Migration Commands
|
||||
==================
|
||||
|
||||
The Init Command
|
||||
|
||||
The Init command (short for initialize) is used to prepare your project for
|
||||
Phinx. This command generates the ``phinx.yml`` file in the root of your
|
||||
project directory.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cd yourapp
|
||||
$ phinx init .
|
||||
|
||||
Open this file in your text editor to setup your project configuration. Please
|
||||
see the :doc:`Configuration <configuration>` chapter for more information.
|
||||
|
||||
The Create Command
|
||||
------------------
|
||||
|
||||
The Create command is used to create a new migration file. It requires one
|
||||
argument: the name of the migration. The migration name should be specified in
|
||||
CamelCase format.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx create MyNewMigration
|
||||
|
||||
Open the new migration file in your text editor to add your database
|
||||
transformations. Phinx creates migration files using the path specified in your
|
||||
``phinx.yml`` file. Please see the :doc:`Configuration <configuration>` chapter
|
||||
for more information.
|
||||
|
||||
You are able to override the template file used by Phinx by supplying an
|
||||
alternative template filename.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx create MyNewMigration --template="<file>"
|
||||
|
||||
You can also supply a template generating class. This class must implement the
|
||||
interface ``Phinx\Migration\CreationInterface``.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx create MyNewMigration --class="<class>"
|
||||
|
||||
In addition to providing the template for the migration, the class can also define
|
||||
a callback that will be called once the migration file has been generated from the
|
||||
template.
|
||||
|
||||
You cannot use ``--template`` and ``--class`` together.
|
||||
|
||||
The Migrate Command
|
||||
-------------------
|
||||
|
||||
The Migrate command runs all of the available migrations, optionally up to a
|
||||
specific version.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx migrate -e development
|
||||
|
||||
To migrate to a specific version then use the ``--target`` parameter or ``-t``
|
||||
for short.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx migrate -e development -t 20110103081132
|
||||
|
||||
Use ``--dry-run`` to print the queries to standard output without executing them
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx migrate --dry-run
|
||||
|
||||
The Rollback Command
|
||||
--------------------
|
||||
|
||||
The Rollback command is used to undo previous migrations executed by Phinx. It
|
||||
is the opposite of the Migrate command.
|
||||
|
||||
You can rollback to the previous migration by using the ``rollback`` command
|
||||
with no arguments.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx rollback -e development
|
||||
|
||||
To rollback all migrations to a specific version then use the ``--target``
|
||||
parameter or ``-t`` for short.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx rollback -e development -t 20120103083322
|
||||
|
||||
Specifying 0 as the target version will revert all migrations.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx rollback -e development -t 0
|
||||
|
||||
To rollback all migrations to a specific date then use the ``--date``
|
||||
parameter or ``-d`` for short.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx rollback -e development -d 2012
|
||||
$ phinx rollback -e development -d 201201
|
||||
$ phinx rollback -e development -d 20120103
|
||||
$ phinx rollback -e development -d 2012010312
|
||||
$ phinx rollback -e development -d 201201031205
|
||||
$ phinx rollback -e development -d 20120103120530
|
||||
|
||||
If a breakpoint is set, blocking further rollbacks, you can override the
|
||||
breakpoint using the ``--force`` parameter or ``-f`` for short.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx rollback -e development -t 0 -f
|
||||
|
||||
Use ``--dry-run`` to print the queries to standard output without executing them
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx rollback --dry-run
|
||||
|
||||
.. note::
|
||||
|
||||
When rolling back, Phinx orders the executed migrations using
|
||||
the order specified in the ``version_order`` option of your
|
||||
``phinx.yml`` file.
|
||||
Please see the :doc:`Configuration <configuration>` chapter for more information.
|
||||
|
||||
The Status Command
|
||||
------------------
|
||||
|
||||
The Status command prints a list of all migrations, along with their current
|
||||
status. You can use this command to determine which migrations have been run.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx status -e development
|
||||
|
||||
This command exits with code 0 if the database is up-to-date (ie. all migrations are up) or one of the following codes otherwise:
|
||||
|
||||
* 1: There is at least one migration left to be executed.
|
||||
* 2: There was a migration run and recorded in the database, but the migration file is now missing.
|
||||
|
||||
The Breakpoint Command
|
||||
----------------------
|
||||
|
||||
The Breakpoint command is used to set breakpoints, allowing you to limit
|
||||
rollbacks. You can toggle the breakpoint of the most recent migration by
|
||||
not supplying any parameters.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx breakpoint -e development
|
||||
|
||||
To toggle a breakpoint on a specific version then use the ``--target``
|
||||
parameter or ``-t`` for short.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx breakpoint -e development -t 20120103083322
|
||||
|
||||
You can remove all the breakpoints by using the ``--remove-all`` parameter
|
||||
or ``-r`` for short.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx breakpoint -e development -r
|
||||
|
||||
Breakpoints are visible when you run the ``status`` command.
|
||||
|
||||
Database Seeding
|
||||
================
|
||||
|
||||
The Seed Create Command
|
||||
-----------------------
|
||||
|
||||
The Seed Create command can be used to create new database seed classes. It
|
||||
requires one argument, the name of the class. The class name should be specified
|
||||
in CamelCase format.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx seed:create MyNewSeeder
|
||||
|
||||
Open the new seed file in your text editor to add your database seed commands.
|
||||
Phinx creates seed files using the path specified in your ``phinx.yml`` file.
|
||||
Please see the :doc:`Configuration <configuration>` chapter for more information.
|
||||
|
||||
The Seed Run Command
|
||||
--------------------
|
||||
|
||||
The Seed Run command runs all of the available seed classes or optionally just
|
||||
one.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx seed:run -e development
|
||||
|
||||
To run only one seed class use the ``--seed`` parameter or ``-s`` for short.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ phinx seed:run -e development -s MyNewSeeder
|
||||
|
||||
Configuration File Parameter
|
||||
----------------------------
|
||||
|
||||
When running Phinx from the command line, you may specify a configuration file
|
||||
using the ``--configuration`` or ``-c`` parameter. In addition to YAML, the
|
||||
configuration file may be the computed output of a PHP file as a PHP array:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
<?php
|
||||
return [
|
||||
"paths" => [
|
||||
"migrations" => "application/migrations"
|
||||
],
|
||||
"environments" => [
|
||||
"default_migration_table" => "phinxlog",
|
||||
"default_database" => "dev",
|
||||
"dev" => [
|
||||
"adapter" => "mysql",
|
||||
"host" => $_ENV['DB_HOST'],
|
||||
"name" => $_ENV['DB_NAME'],
|
||||
"user" => $_ENV['DB_USER'],
|
||||
"pass" => $_ENV['DB_PASS'],
|
||||
"port" => $_ENV['DB_PORT'],
|
||||
]
|
||||
]
|
||||
];
|
||||
|
||||
Phinx auto-detects which language parser to use for files with ``*.yml`` and ``*.php`` extensions. The appropriate
|
||||
parser may also be specified via the ``--parser`` and ``-p`` parameters. Anything other than ``"php"`` is treated as YAML.
|
||||
|
||||
When using a PHP array, you can provide a ``connection`` key with an existing PDO instance. It is also important to pass
|
||||
the database name too, as Phinx requires this for certain methods such as ``hasTable()``:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
<?php
|
||||
return [
|
||||
"paths" => [
|
||||
"migrations" => "application/migrations"
|
||||
],
|
||||
"environments" => [
|
||||
"default_migration_table" => "phinxlog",
|
||||
"default_database" => "dev",
|
||||
"dev" => [
|
||||
"name" => "dev_db",
|
||||
"connection" => $pdo_instance
|
||||
]
|
||||
]
|
||||
];
|
||||
|
||||
Running Phinx in a Web App
|
||||
--------------------------
|
||||
|
||||
Phinx can also be run inside of a web application by using the ``Phinx\Wrapper\TextWrapper``
|
||||
class. An example of this is provided in ``app/web.php``, which can be run as a
|
||||
standalone server:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ php -S localhost:8000 vendor/robmorgan/phinx/app/web.php
|
||||
|
||||
This will create local web server at `<http://localhost:8000>`__ which will show current
|
||||
migration status by default. To run migrations up, use `<http://localhost:8000/migrate>`__
|
||||
and to rollback use `<http://localhost:8000/rollback>`__.
|
||||
|
||||
**The included web app is only an example and should not be used in production!**
|
||||
|
||||
.. note::
|
||||
|
||||
To modify configuration variables at runtime and override ``%%PHINX_DBNAME%%``
|
||||
or other another dynamic option, set ``$_SERVER['PHINX_DBNAME']`` before
|
||||
running commands. Available options are documented in the Configuration page.
|
||||
|
||||
Using Phinx with PHPUnit
|
||||
--------------------------
|
||||
|
||||
Phinx can be used within your unit tests to prepare or seed the database. You can use it programatically :
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
public function setUp ()
|
||||
{
|
||||
$app = new PhinxApplication();
|
||||
$app->setAutoExit(false);
|
||||
$app->run(new StringInput('migrate'), new NullOutput());
|
||||
}
|
||||
|
||||
If you use a memory database, you'll need to give Phinx a specific PDO instance. You can interact with Phinx directly using the Manager class :
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
use PDO;
|
||||
use Phinx\Config\Config;
|
||||
use Phinx\Migration\Manager;
|
||||
use PHPUnit\Framework\TestCase;
|
||||
use Symfony\Component\Console\Input\StringInput;
|
||||
use Symfony\Component\Console\Output\NullOutput;
|
||||
|
||||
class DatabaseTestCase extends TestCase {
|
||||
|
||||
public function setUp ()
|
||||
{
|
||||
$pdo = new PDO('sqlite::memory:', null, null, [
|
||||
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
|
||||
]);
|
||||
$configArray = require('phinx.php');
|
||||
$configArray['environments']['test'] = [
|
||||
'adapter' => 'sqlite',
|
||||
'connection' => $pdo
|
||||
];
|
||||
$config = new Config($configArray);
|
||||
$manager = new Manager($config, new StringInput(' '), new NullOutput());
|
||||
$manager->migrate('test');
|
||||
$manager->seed('test');
|
||||
// You can change default fetch mode after the seeding
|
||||
$this->pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_OBJ);
|
||||
$this->pdo = $pdo;
|
||||
}
|
||||
|
||||
}
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
import sys, os
|
||||
|
||||
# Append the top level directory of the docs, so we can import from the config dir.
|
||||
sys.path.insert(0, os.path.abspath('..'))
|
||||
|
||||
# Pull in all the configuration options defined in the global config file..
|
||||
from config.all import *
|
||||
|
||||
language = 'fr'
|
||||
+308
@@ -0,0 +1,308 @@
|
||||
.. index::
|
||||
single: Configuration
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
When you initialize your project using the :doc:`Init Command<commands>`, Phinx
|
||||
creates a default file called ``phinx.yml`` in the root of your project directory.
|
||||
This file uses the YAML data serialization format.
|
||||
|
||||
If a ``--configuration`` command line option is given, Phinx will load the
|
||||
specified file. Otherwise, it will attempt to find ``phinx.php``, ``phinx.json`` or
|
||||
``phinx.yml`` and load the first file found. See the :doc:`Commands <commands>`
|
||||
chapter for more information.
|
||||
|
||||
.. warning::
|
||||
|
||||
Remember to store the configuration file outside of a publicly accessible
|
||||
directory on your webserver. This file contains your database credentials
|
||||
and may be accidentally served as plain text.
|
||||
|
||||
Note that while JSON and YAML files are *parsed*, the PHP file is *included*.
|
||||
This means that:
|
||||
|
||||
* It must `return` an array of configuration items.
|
||||
* The variable scope is local, i.e. you would need to explicitly declare
|
||||
any global variables your initialization file reads or modifies.
|
||||
* Its standard output is suppressed.
|
||||
* Unlike with JSON and YAML, it is possible to omit environment connection details
|
||||
and instead specify ``connection`` which must contain an initialized PDO instance.
|
||||
This is useful when you want your migrations to interact with your application
|
||||
and/or share the same connection. However remember to also pass the database name
|
||||
as Phinx cannot infer this from the PDO connection.
|
||||
|
||||
::
|
||||
|
||||
<?php
|
||||
require 'app/init.php';
|
||||
|
||||
global $app;
|
||||
$pdo = $app->getDatabase()->getPdo();
|
||||
|
||||
return ['environments' =>
|
||||
[
|
||||
'default_database' => 'development',
|
||||
'development' => [
|
||||
'name' => 'devdb',
|
||||
'connection' => $pdo,
|
||||
]
|
||||
]
|
||||
];
|
||||
|
||||
Migration Paths
|
||||
---------------
|
||||
|
||||
The first option specifies the path to your migration directory. Phinx uses
|
||||
``%%PHINX_CONFIG_DIR%%/db/migrations`` by default.
|
||||
|
||||
.. note::
|
||||
|
||||
``%%PHINX_CONFIG_DIR%%`` is a special token and is automatically replaced
|
||||
with the root directory where your ``phinx.yml`` file is stored.
|
||||
|
||||
In order to overwrite the default ``%%PHINX_CONFIG_DIR%%/db/migrations``, you
|
||||
need to add the following to the yaml configuration.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
paths:
|
||||
migrations: /your/full/path
|
||||
|
||||
You can also provide multiple migration paths by using an array in your configuration:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
paths:
|
||||
migrations:
|
||||
- application/module1/migrations
|
||||
- application/module2/migrations
|
||||
|
||||
You can also use the ``%%PHINX_CONFIG_DIR%%`` token in your path.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
paths:
|
||||
migrations: '%%PHINX_CONFIG_DIR%%/your/relative/path'
|
||||
|
||||
Migrations are captured with ``glob``, so you can define a pattern for multiple
|
||||
directories.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
paths:
|
||||
migrations: '%%PHINX_CONFIG_DIR%%/module/*/{data,scripts}/migrations'
|
||||
|
||||
Custom Migration Base
|
||||
---------------------
|
||||
|
||||
By default all migrations will extend from Phinx's ``AbstractMigration`` class.
|
||||
This can be set to a custom class that extends from ``AbstractMigration`` by
|
||||
setting ``migration_base_class`` in your config:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
migration_base_class: MyMagicalMigration
|
||||
|
||||
Seed Paths
|
||||
----------
|
||||
|
||||
The second option specifies the path to your seed directory. Phinx uses
|
||||
``%%PHINX_CONFIG_DIR%%/db/seeds`` by default.
|
||||
|
||||
.. note::
|
||||
|
||||
``%%PHINX_CONFIG_DIR%%`` is a special token and is automatically replaced
|
||||
with the root directory where your ``phinx.yml`` file is stored.
|
||||
|
||||
In order to overwrite the default ``%%PHINX_CONFIG_DIR%%/db/seeds``, you
|
||||
need to add the following to the yaml configuration.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
paths:
|
||||
seeds: /your/full/path
|
||||
|
||||
You can also provide multiple seed paths by using an array in your configuration:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
paths:
|
||||
seeds:
|
||||
- /your/full/path1
|
||||
- /your/full/path2
|
||||
|
||||
You can also use the ``%%PHINX_CONFIG_DIR%%`` token in your path.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
paths:
|
||||
seeds: '%%PHINX_CONFIG_DIR%%/your/relative/path'
|
||||
|
||||
Environments
|
||||
------------
|
||||
|
||||
One of the key features of Phinx is support for multiple database environments.
|
||||
You can use Phinx to create migrations on your development environment, then
|
||||
run the same migrations on your production environment. Environments are
|
||||
specified under the ``environments`` nested collection. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
environments:
|
||||
default_migration_table: phinxlog
|
||||
default_database: development
|
||||
production:
|
||||
adapter: mysql
|
||||
host: localhost
|
||||
name: production_db
|
||||
user: root
|
||||
pass: ''
|
||||
port: 3306
|
||||
charset: utf8
|
||||
collation: utf8_unicode_ci
|
||||
|
||||
would define a new environment called ``production``.
|
||||
|
||||
In a situation when multiple developers work on the same project and each has
|
||||
a different environment (e.g. a convention such as ``<environment
|
||||
type>-<developer name>-<machine name>``), or when you need to have separate
|
||||
environments for separate purposes (branches, testing, etc) use environment
|
||||
variable `PHINX_ENVIRONMENT` to override the default environment in the yaml
|
||||
file:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
export PHINX_ENVIRONMENT=dev-`whoami`-`hostname`
|
||||
|
||||
Table Prefix and Suffix
|
||||
-----------------------
|
||||
|
||||
You can define a table prefix and table suffix:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
environments:
|
||||
development:
|
||||
....
|
||||
table_prefix: dev_
|
||||
table_suffix: _v1
|
||||
testing:
|
||||
....
|
||||
table_prefix: test_
|
||||
table_suffix: _v2
|
||||
|
||||
Socket Connections
|
||||
------------------
|
||||
|
||||
When using the MySQL adapter, it is also possible to use sockets instead of
|
||||
network connections. The socket path is configured with ``unix_socket``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
environments:
|
||||
default_migration_table: phinxlog
|
||||
default_database: development
|
||||
production:
|
||||
adapter: mysql
|
||||
name: production_db
|
||||
user: root
|
||||
pass: ''
|
||||
unix_socket: /var/run/mysql/mysql.sock
|
||||
charset: utf8
|
||||
|
||||
External Variables
|
||||
------------------
|
||||
|
||||
Phinx will automatically grab any environment variable prefixed with ``PHINX_``
|
||||
and make it available as a token in the config file. The token will have
|
||||
exactly the same name as the variable but you must access it by wrapping two
|
||||
``%%`` symbols on either side. e.g: ``%%PHINX_DBUSER%%``. This is especially
|
||||
useful if you wish to store your secret database credentials directly on the
|
||||
server and not in a version control system. This feature can be easily
|
||||
demonstrated by the following example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
environments:
|
||||
default_migration_table: phinxlog
|
||||
default_database: development
|
||||
production:
|
||||
adapter: mysql
|
||||
host: '%%PHINX_DBHOST%%'
|
||||
name: '%%PHINX_DBNAME%%'
|
||||
user: '%%PHINX_DBUSER%%'
|
||||
pass: '%%PHINX_DBPASS%%'
|
||||
port: 3306
|
||||
charset: utf8
|
||||
|
||||
Supported Adapters
|
||||
------------------
|
||||
|
||||
Phinx currently supports the following database adapters natively:
|
||||
|
||||
* `MySQL <http://www.mysql.com/>`_: specify the ``mysql`` adapter.
|
||||
* `PostgreSQL <http://www.postgresql.org/>`_: specify the ``pgsql`` adapter.
|
||||
* `SQLite <http://www.sqlite.org/>`_: specify the ``sqlite`` adapter.
|
||||
* `SQL Server <http://www.microsoft.com/sqlserver>`_: specify the ``sqlsrv`` adapter.
|
||||
|
||||
SQLite
|
||||
~~~~~~
|
||||
|
||||
Declaring an SQLite database uses a simplified structure:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
environments:
|
||||
development:
|
||||
adapter: sqlite
|
||||
name: ./data/derby
|
||||
testing:
|
||||
adapter: sqlite
|
||||
memory: true # Setting memory to *any* value overrides name
|
||||
|
||||
SQL Server
|
||||
~~~~~~~~~~
|
||||
|
||||
When using the ``sqlsrv`` adapter and connecting to a named instance you should
|
||||
omit the ``port`` setting as SQL Server will negotiate the port automatically.
|
||||
Additionally, omit the ``charset: utf8`` or change to ``charset: 65001`` which
|
||||
corresponds to UTF8 for SQL Server.
|
||||
|
||||
Custom Adapters
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
You can provide a custom adapter by registering an implementation of the
|
||||
``Phinx\\Db\\Adapter\\AdapterInterface`` with ``AdapterFactory``:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$name = 'fizz';
|
||||
$class = 'Acme\Adapter\FizzAdapter';
|
||||
|
||||
AdapterFactory::instance()->registerAdapter($name, $class);
|
||||
|
||||
Adapters can be registered any time before `$app->run()` is called, which normally
|
||||
called by `bin/phinx`.
|
||||
|
||||
Aliases
|
||||
-------
|
||||
|
||||
Template creation class names can be aliased and used with the ``--class`` command line option for the :doc:`Create Command <commands>`.
|
||||
|
||||
The aliased classes will still be required to implement the ``Phinx\Migration\CreationInterface`` interface.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
aliases:
|
||||
permission: \Namespace\Migrations\PermissionMigrationTemplateGenerator
|
||||
view: \Namespace\Migrations\ViewMigrationTemplateGenerator
|
||||
|
||||
Version Order
|
||||
-------------
|
||||
|
||||
When rolling back or printing the status of migrations, Phinx orders the executed migrations according to the
|
||||
``version_order`` option, which can have the following values:
|
||||
|
||||
* ``creation`` (the default): migrations are ordered by their creation time, which is also part of their filename.
|
||||
* ``execution``: migrations are ordered by their execution time, also known as start time.
|
||||
+11
@@ -0,0 +1,11 @@
|
||||
Contenus
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
index
|
||||
migrations
|
||||
seeding
|
||||
commands
|
||||
configuration
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
Phinx Migrations
|
||||
################
|
||||
|
||||
Phinx est un utilitaire autonome en ligne de commande pour gérer les Migrations de bases de données. Le plugin officiel de Migrations de CakePHP est basé sur cet outil.
|
||||
|
||||
Phinx rend ridiculement simple la gestion des migrations de bases de données pour vos applications PHP. En moins de 5 minutes,
|
||||
vous pouvez installer Composer et créer votre première migration de base de données. Phinx ne s'occupe que de la migration des
|
||||
bases de données, il laisse de côté les aspects ORM de la base de données et le cadre applicatif.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Les bons développeurs gèrent toujours leurs codes sources avec un outil de gestion de versions,
|
||||
alors pourquoi ne feraient-ils pas la même chose avec leurs schémas de bases de données.
|
||||
|
||||
Phinx permet aux développeurs de modifier et de manipuler leurs bases de données d'une façon claire et concise. Il évite
|
||||
d'avoir à écrire du SQL à la main et offre à la place une API puissante pour écrire des scripts de migration en utilisant PHP.
|
||||
Les développeurs peuvent alors versionner ces fichiers de migration en utilisant leur outil de versionnement préféré. Cela rend
|
||||
les migrations Phinx indépendantes des moteurs de base de données. Phinx conserve la trace des migrations précédentes, cela
|
||||
permet de se concentrer un peu plus sur l'amélioration de votre application et un peu moins sur l'état de votre base de
|
||||
données.
|
||||
|
||||
Objectifs
|
||||
=========
|
||||
|
||||
Phinx a été développé avec les objectifs suivants en tête :
|
||||
|
||||
* Être portable entre les principaux moteurs de base de données.
|
||||
* Être indépendant de tout framework PHP.
|
||||
* Être aisement installable.
|
||||
* Être utilisable facilement en ligne de commande.
|
||||
* Être intégrable avec d'autres outils PHP (Phing, PHPUnit) et des frameworks web.
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
Phinx devrait être installé en utilisant Composer, qui est un outil pour la gestion des dépendances en PHP. Visiter le site
|
||||
internet de `Composer <https://getcomposer.org/>`_ pour avoir plus d’informations.
|
||||
|
||||
.. note::
|
||||
|
||||
Phinx a besoin au minimum de PHP 5.4 (ou supérieur)
|
||||
|
||||
Pour installer Phinx, il suffit simplement de l'appeler via Composer
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
php composer.phar require robmorgan/phinx
|
||||
|
||||
Créez les dossiers ``db/migrations`` dans votre projet en vous assurant que les droits sont bien configurés.
|
||||
C’est à cet endroit que vos fichiers de migrations devraient être créés et laissés.
|
||||
|
||||
Phinx peut maintenant être exécuté depuis la racine de votre projet.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
vendor/bin/phinx init
|
||||
+1305
File diff suppressed because it is too large.
Load diff
+217
@@ -0,0 +1,217 @@
|
||||
.. index::
|
||||
single: Database Seeding
|
||||
|
||||
Database Seeding
|
||||
================
|
||||
|
||||
In version 0.5.0 Phinx introduced support for seeding your database with test
|
||||
data. Seed classes are a great way to easily fill your database with data after
|
||||
it's created. By default they are stored in the ``seeds`` directory; however,
|
||||
this path can be changed in your configuration file.
|
||||
|
||||
.. note::
|
||||
|
||||
Database seeding is entirely optional, and Phinx does not create a ``seeds``
|
||||
directory by default.
|
||||
|
||||
Creating a New Seed Class
|
||||
-------------------------
|
||||
|
||||
Phinx includes a command to easily generate a new seed class:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ php vendor/bin/phinx seed:create UserSeeder
|
||||
|
||||
If you have specified multiple seed paths, you will be asked to select which
|
||||
path to create the new seed class in.
|
||||
|
||||
It is based on a skeleton template::
|
||||
|
||||
<?php
|
||||
|
||||
use Phinx\Seed\AbstractSeed;
|
||||
|
||||
class MyNewSeeder extends AbstractSeed
|
||||
{
|
||||
/**
|
||||
* Run Method.
|
||||
*
|
||||
* Write your database seeder using this method.
|
||||
*
|
||||
* More information on writing seeders is available here:
|
||||
* http://docs.phinx.org/en/latest/seeding.html
|
||||
*/
|
||||
public function run()
|
||||
{
|
||||
|
||||
}
|
||||
}
|
||||
|
||||
The AbstractSeed Class
|
||||
----------------------
|
||||
|
||||
All Phinx seeds extend from the ``AbstractSeed`` class. This class provides the
|
||||
necessary support to create your seed classes. Seed classes are primarily used
|
||||
to insert test data.
|
||||
|
||||
The Run Method
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
The run method is automatically invoked by Phinx when you execute the `seed:run`
|
||||
command. You should use this method to insert your test data.
|
||||
|
||||
.. note::
|
||||
|
||||
Unlike with migrations, Phinx does not keep track of which seed classes have
|
||||
been run. This means database seeders can be run repeatedly. Keep this in
|
||||
mind when developing them.
|
||||
|
||||
Inserting Data
|
||||
--------------
|
||||
|
||||
Using The Table Object
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Seed classes can also use the familiar ``Table`` object to insert data. You can
|
||||
retrieve an instance of the Table object by calling the ``table()`` method from
|
||||
within your seed class and then use the ``insert()`` method to insert data::
|
||||
|
||||
<?php
|
||||
use Phinx\Seed\AbstractSeed;
|
||||
|
||||
class PostsSeeder extends AbstractSeed
|
||||
{
|
||||
public function run()
|
||||
{
|
||||
$data = [
|
||||
[
|
||||
'body' => 'foo',
|
||||
'created' => date('Y-m-d H:i:s'),
|
||||
],
|
||||
[
|
||||
'body' => 'bar',
|
||||
'created' => date('Y-m-d H:i:s'),
|
||||
]
|
||||
];
|
||||
|
||||
$posts = $this->table('posts');
|
||||
$posts->insert($data)
|
||||
->save();
|
||||
}
|
||||
}
|
||||
|
||||
.. note::
|
||||
|
||||
You must call the ``save()`` method to commit your data to the table. Phinx
|
||||
will buffer data until you do so.
|
||||
|
||||
Integrating with the Faker library
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It's trivial to use the awesome
|
||||
`Faker library <https://github.com/fzaninotto/Faker>`_ in your seed classes.
|
||||
Simply install it using Composer:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ composer require fzaninotto/faker
|
||||
|
||||
Then use it in your seed classes::
|
||||
|
||||
<?php
|
||||
|
||||
use Phinx\Seed\AbstractSeed;
|
||||
|
||||
class UserSeeder extends AbstractSeed
|
||||
{
|
||||
public function run()
|
||||
{
|
||||
$faker = Faker\Factory::create();
|
||||
$data = [];
|
||||
for ($i = 0; $i < 100; $i++) {
|
||||
$data[] = [
|
||||
'username' => $faker->userName,
|
||||
'password' => sha1($faker->password),
|
||||
'password_salt' => sha1('foo'),
|
||||
'email' => $faker->email,
|
||||
'first_name' => $faker->firstName,
|
||||
'last_name' => $faker->lastName,
|
||||
'created' => date('Y-m-d H:i:s'),
|
||||
];
|
||||
}
|
||||
|
||||
$this->insert('users', $data);
|
||||
}
|
||||
}
|
||||
|
||||
Truncating Tables
|
||||
-----------------
|
||||
|
||||
In addition to inserting data Phinx makes it trivial to empty your tables using
|
||||
the SQL ``TRUNCATE`` command::
|
||||
|
||||
<?php
|
||||
|
||||
use Phinx\Seed\AbstractSeed;
|
||||
|
||||
class UserSeeder extends AbstractSeed
|
||||
{
|
||||
public function run()
|
||||
{
|
||||
$data = [
|
||||
[
|
||||
'body' => 'foo',
|
||||
'created' => date('Y-m-d H:i:s'),
|
||||
],
|
||||
[
|
||||
'body' => 'bar',
|
||||
'created' => date('Y-m-d H:i:s'),
|
||||
]
|
||||
];
|
||||
|
||||
$posts = $this->table('posts');
|
||||
$posts->insert($data)
|
||||
->save();
|
||||
|
||||
// empty the table
|
||||
$posts->truncate();
|
||||
}
|
||||
}
|
||||
|
||||
.. note::
|
||||
|
||||
SQLite doesn't natively support the ``TRUNCATE`` command so behind the scenes
|
||||
``DELETE FROM`` is used. It is recommended to call the ``VACUUM`` command
|
||||
after truncating a table. Phinx does not do this automatically.
|
||||
|
||||
Executing Seed Classes
|
||||
----------------------
|
||||
|
||||
This is the easy part. To seed your database, simply use the ``seed:run`` command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ php vendor/bin/phinx seed:run
|
||||
|
||||
By default, Phinx will execute all available seed classes. If you would like to
|
||||
run a specific class, simply pass in the name of it using the ``-s`` parameter:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ php vendor/bin/phinx seed:run -s UserSeeder
|
||||
|
||||
You can also run multiple seeders:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ php vendor/bin/phinx seed:run -s UserSeeder -s PermissionSeeder -s LogSeeder
|
||||
|
||||
You can also use the ``-v`` parameter for more output verbosity:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ php vendor/bin/phinx seed:run -v
|
||||
|
||||
The Phinx seed functionality provides a simple mechanism to easily and repeatably
|
||||
insert test data into your database.
|
||||
Reference in new issue
Block a user