Doctrine DBAL
  1. Doctrine DBAL
  2. DBAL-602

Deprecate Migrations in favor of stable tools

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      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.

        Activity

        Benjamin Eberlei created issue -
        Benjamin Eberlei made changes -
        Field Original Value New Value
        Fix Version/s 2.5 [ 10523 ]
        Hide
        Christophe Coevoet added a comment -

        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.

        Show
        Christophe Coevoet added a comment - 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.
        Hide
        Benjamin Eberlei added a comment -

        Christophe Coevoet 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.

        Show
        Benjamin Eberlei added a comment - Christophe Coevoet 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.
        Benjamin Eberlei made changes -
        Description 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.

        {code}
        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);
        }
        {code}

        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.
        Hide
        Miha Vrhovnik added a comment -
        Show
        Miha Vrhovnik added a comment - There is also http://dbv.vizuina.com/
        Hide
        Jonathan Cardoso Machado added a comment -

        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?

        Show
        Jonathan Cardoso Machado added a comment - 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?

        This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

        • Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DBAL-602, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Benjamin Eberlei
          • Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated: