skylord123/mycomments-api
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

The start of something beautiful

Browse Source
This commit is contained in:
Skylar Sadlier
2024-09-11 22:48:07 -06:00
parent 45acea47f3
commit f5997ee5ec
5614 changed files with 630696 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
vendor/doctrine/doctrine-migrations-bundle/Resources/doc/index.rst
Vendored
+467
View File
@@ -0,0 +1,467 @@
DoctrineMigrationsBundle
========================
Database migrations are a way to safely update your database schema both locally
and on production. Instead of running the ``doctrine:schema:update`` command or
applying the database changes manually with SQL statements, migrations allow to
replicate the changes in your database schema in a safe manner.
Migrations are available in Symfony applications via the `DoctrineMigrationsBundle`_,
which uses the external `Doctrine Database Migrations`_ library. Read the
`documentation`_ of that library if you need a general introduction about migrations.
Installation
------------
Run this command in your terminal:
.. code-block:: terminal
$ composer require doctrine/doctrine-migrations-bundle "^3.0"
If you don't use `Symfony Flex`_, you must enable the bundle manually in the application:
.. code-block:: php
// config/bundles.php
// in older Symfony apps, enable the bundle in app/AppKernel.php
return [
// ...
Doctrine\Bundle\MigrationsBundle\DoctrineMigrationsBundle::class => ['all' => true],
];
Configuration
-------------
If you use Symfony Flex, the ``doctrine_migrations.yaml`` config file is created
automatically. Otherwise, create the following file and configure it for your
application:
.. code-block:: yaml
# config/packages/doctrine_migrations.yaml
doctrine_migrations:
# List of namespace/path pairs to search for migrations, at least one required
migrations_paths:
'App\Migrations': '%kernel.project_dir%/src/App'
'AnotherApp\Migrations': '/path/to/other/migrations'
'SomeBundle\Migrations': '@SomeBundle/Migrations'
# List of additional migration classes to be loaded, optional
migrations:
- 'App\Migrations\Version123'
- 'App\Migrations\Version123'
# Connection to use for the migrations
connection: default
# Entity manager to use for migrations. This overrides the "connection" setting.
em: default
storage:
# Default (SQL table) metadata storage configuration
table_storage:
table_name: 'doctrine_migration_versions'
version_column_name: 'version'
version_column_length: 192
executed_at_column_name: 'executed_at'
# Possible values: "BY_YEAR", "BY_YEAR_AND_MONTH", false
organize_migrations: false
# Path to your custom migrations template
custom_template: ~
# Run all migrations in a transaction.
all_or_nothing: false
# Adds an extra check in the generated migrations to ensure that is executed on the same database type.
check_database_platform: true
# Whether or not to wrap migrations in a single transaction.
transactional: true
# Whether or not to enable the profiler collector to calculate and visualize migration status. This adds some queries overhead.
# enable_profiler: false
services:
# Custom migration sorting service id
'Doctrine\Migrations\Version\Comparator': ~
# Custom migration classes factory
'Doctrine\Migrations\Version\MigrationFactory': ~
factories:
# Custom migration sorting service id via callables (MyCallableFactory must be a callable)
'Doctrine\Migrations\Version\Comparator': 'MyCallableFactory'
- The ``services`` node allows you to provide custom services to the underlying ``DependencyFactory`` part of ``doctrine/migrations``.
- The node ``factories`` is similar to ``services``, with the difference that it accepts only callables.
The provided callable must return the service to be passed to the ``DependencyFactory``.
The callable will receive as first argument the ``DependencyFactory`` itself,
allowing you to fetch other dependencies from the factory while instantiating your custom dependencies.
Usage
-----
All of the migrations functionality is contained in a few console commands:
.. code-block:: terminal
doctrine
doctrine:migrations:current [current] Outputs the current version.
doctrine:migrations:diff [diff] Generate a migration by comparing your current database to your mapping information.
doctrine:migrations:dump-schema [dump-schema] Dump the schema for your database to a migration.
doctrine:migrations:execute [execute] Execute a single migration version up or down manually.
doctrine:migrations:generate [generate] Generate a blank migration class.
doctrine:migrations:latest [latest] Outputs the latest version number
doctrine:migrations:migrate [migrate] Execute a migration to a specified version or the latest available version.
doctrine:migrations:rollup [rollup] Roll migrations up by deleting all tracked versions and inserting the one version that exists.
doctrine:migrations:status [status] View the status of a set of migrations.
doctrine:migrations:up-to-date [up-to-date] Tells you if your schema is up-to-date.
doctrine:migrations:version [version] Manually add and delete migration versions from the version table.
doctrine:migrations:sync-metadata-storage [sync-metadata-storage] Ensures that the metadata storage is at the latest version.
doctrine:migrations:list [list-migrations] Display a list of all available migrations and their status.
Start by getting the status of migrations in your application by running
the ``status`` command:
.. code-block:: terminal
$ php bin/console doctrine:migrations:status
This command will show you generic information about the migration status, such as how many migrations have been
already executed, which still need to run, and the database in use.
Now, you can start working with migrations by generating a new blank migration
class. Later, you'll learn how Doctrine can generate migrations automatically
for you.
.. code-block:: terminal
$ php bin/console doctrine:migrations:generate
Have a look at the newly generated migration class and you will see something
like the following:
.. code-block:: php
declare(strict_types=1);
namespace DoctrineMigrations;
use Doctrine\DBAL\Schema\Schema;
use Doctrine\Migrations\AbstractMigration;
/**
* Auto-generated Migration: Please modify to your needs!
*/
final class Version20180605025653 extends AbstractMigration
{
public function getDescription() : string
{
return '';
}
public function up(Schema $schema) : void
{
// this up() migration is auto-generated, please modify it to your needs
}
public function down(Schema $schema) : void
{
// this down() migration is auto-generated, please modify it to your needs
}
}
If you run the ``status`` command again it will now show that you have one new
migration to execute:
.. code-block:: terminal
$ php bin/console doctrine:migrations:status
Now you can add some migration code to the ``up()`` and ``down()`` methods and
finally migrate when you're ready:
.. code-block:: terminal
$ php bin/console doctrine:migrations:migrate 'DoctrineMigrations\Version20180605025653'
For more information on how to write the migrations themselves (i.e. how to
fill in the ``up()`` and ``down()`` methods), see the official Doctrine Migrations
`documentation`_.
Running Migrations during Deployment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Of course, the end goal of writing migrations is to be able to use them to
reliably update your database structure when you deploy your application.
By running the migrations locally (or on a beta server), you can ensure that
the migrations work as you expect.
When you do finally deploy your application, you just need to remember to run
the ``doctrine:migrations:migrate`` command. Internally, Doctrine creates
a ``migration_versions`` table inside your database and tracks which migrations
have been executed there. So, no matter how many migrations you've created
and executed locally, when you run the command during deployment, Doctrine
will know exactly which migrations it hasn't run yet by looking at the ``migration_versions``
table of your production database. Regardless of what server you're on, you
can always safely run this command to execute only the migrations that haven't
been run yet on *that* particular database.
Skipping Migrations
~~~~~~~~~~~~~~~~~~~
You can skip single migrations by explicitly adding them to the ``migration_versions`` table:
.. code-block:: terminal
$ php bin/console doctrine:migrations:version 'App\Migrations\Version123' --add
.. tip::
Pay attention to the single quotes (``'``) used in the command above, without them
or with the double quotes (``"``) the command will not work properly.
Doctrine will then assume that this migration has already been run and will ignore it.
Migration Dependencies
----------------------
Migrations can have dependencies on external services (such as geolocation, mailer, data processing services...) that
can be used to have more powerful migrations. Those dependencies are not automatically injected into your migrations
but need to be injected using custom migrations factories.
Here is an example on how to inject the service container into your migrations:
.. configuration-block::
.. code-block:: yaml
# config/packages/doctrine_migrations.yaml
doctrine_migrations:
services:
'Doctrine\Migrations\Version\MigrationFactory': 'App\Migrations\Factory\MigrationFactoryDecorator'
# config/services.yaml
services:
App\Migrations\Factory\MigrationFactoryDecorator:
decorates: 'doctrine.migrations.migrations_factory'
arguments: ['@.inner', '@service_container']
.. code-block:: php
declare(strict_types=1);
namespace App\Migrations\Factory;
use Doctrine\Migrations\AbstractMigration;
use Doctrine\Migrations\Version\MigrationFactory;
use Symfony\Component\DependencyInjection\ContainerAwareInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
class MigrationFactoryDecorator implements MigrationFactory
{
private $migrationFactory;
private $container;
public function __construct(MigrationFactory $migrationFactory, ContainerInterface $container)
{
$this->migrationFactory = $migrationFactory;
$this->container = $container;
}
public function createVersion(string $migrationClassName): AbstractMigration
{
$instance = $this->migrationFactory->createVersion($migrationClassName);
if ($instance instanceof ContainerAwareInterface) {
$instance->setContainer($this->container);
}
return $instance;
}
}
.. tip::
If your migration class implements the interface ``Symfony\Component\DependencyInjection\ContainerAwareInterface``
this bundle will automatically inject the default symfony container into your migration class
(this because the ``MigrationFactoryDecorator`` shown in this example is the default migration factory used by this bundle).
Generating Migrations Automatically
-----------------------------------
In reality, you should rarely need to write migrations manually, as the migrations
library can generate migration classes automatically by comparing your Doctrine
mapping information (i.e. what your database *should* look like) with your
actual current database structure.
For example, suppose you create a new ``User`` entity and add mapping information
for Doctrine's ORM:
.. configuration-block::
.. code-block:: php-annotations
// src/Entity/User.php
namespace App\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* @ORM\Entity
* @ORM\Table(name="hello_user")
*/
class User
{
/**
* @ORM\Id
* @ORM\Column(type="integer")
* @ORM\GeneratedValue(strategy="AUTO")
*/
private $id;
/**
* @ORM\Column(type="string", length=255)
*/
private $name;
.. code-block:: yaml
# config/doctrine/User.orm.yaml
App\Entity\User:
type: entity
table: user
id:
id:
type: integer
generator:
strategy: AUTO
fields:
name:
type: string
length: 255
.. code-block:: xml
<!-- config/doctrine/User.orm.xml -->
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">
<entity name="App\Entity\User" table="user">
<id name="id" type="integer" column="id">
<generator strategy="AUTO"/>
</id>
<field name="name" column="name" type="string" length="255" />
</entity>
</doctrine-mapping>
With this information, Doctrine is now ready to help you persist your new
``User`` object to and from the ``user`` table. Of course, this table
doesn't exist yet! Generate a new migration for this table automatically by
running the following command:
.. code-block:: terminal
$ php bin/console doctrine:migrations:diff
You should see a message that a new migration class was generated based on
the schema differences. If you open this file, you'll find that it has the
SQL code needed to create the ``user`` table. Next, run the migration
to add the table to your database:
.. code-block:: terminal
$ php bin/console doctrine:migrations:migrate
The moral of the story is this: after each change you make to your Doctrine
mapping information, run the ``doctrine:migrations:diff`` command to automatically
generate your migration classes.
If you do this from the very beginning of your project (i.e. so that even
the first tables were loaded via a migration class), you'll always be able
to create a fresh database and run your migrations in order to get your database
schema fully up to date. In fact, this is an easy and dependable workflow
for your project.
If you don't want to use this workflow and instead create your schema via
``doctrine:schema:create``, you can tell Doctrine to skip all existing migrations:
.. code-block:: terminal
$ php bin/console doctrine:migrations:version --add --all
Otherwise Doctrine will try to run all migrations, which probably will not work.
Manual Tables
-------------
It is a common use case, that in addition to your generated database structure
based on your doctrine entities you might need custom tables. By default such
tables will be removed by the ``doctrine:migrations:diff`` command.
If you follow a specific scheme you can configure doctrine/dbal to ignore those
tables. Let's say all custom tables will be prefixed by ``t_``. In this case you
just have to add the following configuration option to your doctrine configuration:
.. configuration-block::
.. code-block:: yaml
doctrine:
dbal:
schema_filter: ~^(?!t_)~
.. code-block:: xml
<doctrine:dbal schema-filter="~^(?!t_)~" />
.. code-block:: php
$container->loadFromExtension('doctrine', array(
'dbal' => array(
'schema_filter' => '~^(?!t_)~',
// ...
),
// ...
));
This ignores the tables, and any named objects such as sequences, on the DBAL level and they will be ignored by the diff command.
Note that if you have multiple connections configured then the ``schema_filter`` configuration
will need to be placed per-connection.
Troubleshooting out of sync metadata storage issue
--------------------------------------------------
``doctrine/migrations`` relies on a properly configured Database server version in the connection string to manage the table storing the
migrations, also known as the metadata storage.
If you encounter the error ``The metadata storage is not up to date, please run the sync-metadata-storage command to fix this issue.``
when running the command ``doctrine:migrations:migrate`` or the suggested command itself ``doctrine:migrations:sync-metadata-storage`` please
check the database connection string, and make sure that the proper server version is defined. If you are running a MariaDB database,
you should prefix the server version with ``mariadb-`` (ex: ``mariadb-10.2.12``). See the `configuring_database`_ section.
Example connection string for MariaDB:
.. code-block:: terminal
DATABASE_URL=mysql://root:@127.0.0.1:3306/testtest?serverVersion=mariadb-10.4.11
.. _documentation: https://www.doctrine-project.org/projects/doctrine-migrations/en/current/index.html
.. _configuring_database: https://symfony.com/doc/current/doctrine.html#configuring-the-database
.. _DoctrineMigrationsBundle: https://github.com/doctrine/DoctrineMigrationsBundle
.. _`Doctrine Database Migrations`: https://github.com/doctrine/migrations
.. _`Symfony Flex`: https://symfony.com/doc/current/setup/flex.html