Skip to content

Loading…

DBAL-602: Deprecate Migrations in favor of stable tools #1816

Open
doctrinebot opened this Issue · 7 comments

4 participants

@doctrinebot

Jira issue originally created by user @beberlei:

The Migrations project is very big and currently unmaintained, even if there is definately need for a solution of the migration problem.

The idea would be introduce a subcomponent in DBAL that delegates this to proven tools (DbDeploy and Liquibase, and Phinx for PHP based).

The functionality Doctrine should provide is integration with the \Doctrine\DBAL\Schema API. Three operations come to mind:

  • status - What version are we? Do we need to execute more versions?
  • migrate - Execute the migration tool
  • create-migration - Create a new migration file of the underlying platform.

The last operation needs to check if no versions need to be applied at the moment.

interface MigrationTool
{
   /*** @return MigrationCurrentStatus **/
   public function getStatus();

   /*** @return MigrationPerformedStatus **/
   public function migrate($toVersion = null);

   /*** @return MigrationRolledBackStatus **/
   public function rollback($toVersion = null);

   /*** @return MigrationCreatedStatus **/
   public function create(Schema $toSchema);
}

Every tool implements this interface and then we need 3 new commands for "status", "migrate" and "rollback". The "create" command can only be implemented in the context of the ORM.

@doctrinebot

Comment created by stof:

What is the idea here ?

I don't agree about removing the Migrations project in favor of using only the schema diff tool (which we already have as a command in the ORM btw). Migrating is not only about updating the schema. It also requires migrating data. Otherwise, it is not safe to use in production. This is why the {doctrine:schema:update} command displays a warning before running.
A good example is adding a new non-nullable unique field. Applying the schema update works on an empty DB but fails when the table already contains data.

@doctrinebot

Comment created by @beberlei:

[~stof] The idea is not to keep only ORM Schema-Tool, which is really only a Dev-Tool. We would rather add support for DbDeploy, Liquibase and Phinx into DBAL via some integration sub-component and using DBAL\Schema to create migration files for their formats.

@doctrinebot

Comment created by mvrhov:

There is also http://dbv.vizuina.com/

@doctrinebot

Comment created by jcm:

The command line support is going to stay right? The idea here is to use third party deploy framework, but with specific bindings to use with Doctrine, Am I right?

@doctrinebot

Comment created by jcm:

@beberlei Can we get an update here? Is this still planned for 2.6?

@beberlei beberlei was assigned by doctrinebot
@doctrinebot doctrinebot added this to the 2.6 milestone
@adamelso

Is this issue still relevant? This release would suggest otherwise.

@deeky666
Doctrine member

/cc @beberlei @kimhemsoe you guys had something ongoing and in mind about it...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.