[WIP] 2.0 Prototype #162

wants to merge 28 commits into


None yet

Pull-Request for Discussion of Doctrine Migrations 2.0 Prototype. Text is copied from new README.md.

Please view the rewrite from the branches screen, the Diff isn't very valuable: https://github.com/doctrine/migrations/tree/Rewrite

Starting points are:

Migrations helps developers migrate database schema and data in a simple and reproducible way.
It is currently in alpha version after a full rewrite of its precedessor, version 1.0 that
never left alpha status.

The goal of the rewrite is to reach a stable version as soon as possible,
hopefully leaving the long period of rather unstable migrations in Doctrine
behind us.

The current verion aims to solve various problems:

  • Remove reliance on Schema API of DBAL at runtime, because it proved to be a source
    of bugs and when executed with reproduceability in mind.
  • Remove ability to migrate down. Downmigrations are not possible for 100% of up cases
    and you can therefore not rely on this feature to work. Providing this feature
    only adds a false sense of safety that can bite you hard.
  • Remove ability to generate migrations by diff. This is not a feature Migrations
    should provide, instead it only works when you have two schemas present like
    in the ORM and should be provided there.
  • Introduce SQL file based migrations as default for the 80% use-case, leaving
    PHP based migrations for only complex scenarios.
  • Improve ability to check executed SQL beforehand (dry-run).
  • Improve information about migrations
  • Add explicit handling for failed migrations
  • Simplify code-base and reduce code complexity, decouple core from DBAL and Symfony Console.
    This should improve integration of Migrations into other libraries and frameworks.


  • Add Symfony Console and PHAR Generation
  • Tests for migration failures
  • Dry-Run mode
  • Multi-Platform migrations (with subdirectory SqlFileLoader)
  • Documentation


Doctrine Migrations updates a database schema from one version to another using
a concept called migration. Each migration has a version and a description.
Versions MUST be unique.

From a configured directory Doctrine loads SQL- and PHP-based migrations, where
SQL is used for simple tasks and PHP can be used for more complex operations.

Doctrine sorts all migrations by version and executes them in order.

Migration files have to be in the following format or an error will be thrown:


Valid filenames include:

  • V1_Test.sql
  • V1.1_TestPatch.php
  • V2_Add_New_Column.sql

SQL migrations contain just SQL statements to be executed.

DBAL PHP Migrations need to implement an interface Doctrine\Migrations\DBAL\DBALMigration:


use Doctrine\Migrations\DBAL\DBALMigration;
use Doctrine\DBAL\Connection;

class V2_Batch implements DBALMigration
    public function migrate(Connection $connection)
        $connection->insert('test', array('id' => 1, 'val' => 'Hello World!'));


You can use Doctrine Migrations in two ways:

  • As a standalone PHAR
  • Embedded into your application or framework

Standalone Phar

In case of the standalone PHAR, you need to provide a configuration file named
migrations.ini in the direcetory you are executing the migrations command
in. The file format is INI, here is an example:

script_directory = "migrations/"
allow_init_on_migrate = true
validate_on_migrate = true
out_of_order_migrations_allowed = true

driver = "pdo_mysql"
host = "localhost"
dbname = "mydb"
user = "root"
password = ""

You can also pass the path to the file as an option to the migrations command.


To use migrations embedded you need to obtain an instance of Doctrine\Migrations\Migrations,
which is a facade to all migration operations.

The dependencies for this object are:

  • An instance of Doctrine\Migrations\Configuration
  • An implementation of Doctrine\Migrations\MetadataStorage, when using DBAL and a metadata table
    you can just use Doctrine\Migrations\DBAL\TableMetadataStorage.
  • An instance of Doctrine\Migrations\Executor\ExecutorRegistry with at least one or many
    executors attached that can perform migrations.
  • An implementation of Doctrine\Migrations\Loader\Loader that knows how to load migrations.

You can see an example of this in the Doctrine\Migrations\DBAL\Factory class that is used
by the standalone component:

use Doctrine\Migrations\Migrations;
use Doctrine\Migrations\Configuration;
use Doctrine\Migrations\Loader\ChainLoader;
use Doctrine\Migrations\Executor\ExecutorRegistry;
use Doctrine\Migrations\DBAL\Loader;
use Doctrine\Migrations\DBAL\Executor;
use Doctrine\DBAL\DriverManager;

$configuration = new Configuration();
$connection = DriverManager::getConnection($data['db']);

$chainLoader = new ChainLoader();
$chainLoader->add(new Loader\SqlFileLoader());
$chainLoader->add(new Loader\PhpFileLoader());

$executorRegistry = new ExecutorRegistry();
$executorRegistry->add(new Executor\SqlFileExecutor($connection));
$executorRegistry->add(new Executor\PhpFileExecutor($connection));

$migrations = new Migrations(
    new TableMetadataStorage($connection, $configuration->getScriptDirectory()),
beberlei added some commits Feb 9, 2014
@beberlei beberlei Remove old stuff. 31b5730
@beberlei beberlei Start with Migrations facade API. c447e5b
@beberlei beberlei Add more tests. 3a41203
@beberlei beberlei Refactor MetadataStorage API a little, introduce MigrationStatus. c392788
@beberlei beberlei Refactor towards task based approach to decouple dependencies and mak…
…e code testable.
@beberlei beberlei Reintroduce test. fe0afdf
@beberlei beberlei Test Repair Task. 2fc1d9c
@beberlei beberlei MigrateTask with test. f0bc335
@beberlei beberlei Another test for repair necesary. 42d7000
@beberlei beberlei Test execution of migration. 7b4c2f6
@beberlei beberlei Add test for MigrationStatus#needsRepair 6cf4322
@beberlei beberlei Refactor setter for success away, start populating more data on migra…
…tion info.
@beberlei beberlei Refactor MigrateTask e751f3f
@beberlei beberlei Improve migrate algorithm and rework some of the interactions. a18e87e
@beberlei beberlei Fix Migrate task integration test. dc031a0
@beberlei beberlei Some improvements on DBAL namespace. b87bfe6
@beberlei beberlei Rename MigrationCollection => MigrationSet 5e12f8b
@beberlei beberlei Introduce Loader and SqlFileLoader with test. Add factory method for …
…MigrationInfo in tests.
@beberlei beberlei Refactor SqlFileLoader into AbstractFileLoader and reuse in PhpFileLo…
@beberlei beberlei Integrate Loader into Migrations main script. 105852f
@beberlei beberlei Work on last missing pieces for first integration: TableMetadataStora…
…ge + ChainLoader.
@beberlei beberlei Finalize TableMetadataStorage. 8cad4f8
@beberlei beberlei Add testcase for MigrationStatus#getOustandingMigrations. 8c929ca
@beberlei beberlei Add tests for MigrationSet. fed7dcc
@beberlei beberlei Fix bug in AbstractFileLoader. 9132493
@beberlei beberlei Rewrite README.md, Add DBAL IntegrationTest and fix several small pro…
…blems related.
stof commented Mar 24, 2014

I find the down migrations quite handy when working on several branches in parallel and one of them contains a DB migration, to allow going back to the other branch. I'm wondering how such workflow could work.


Why not migrations.xml?


@stof Migration SQL should always be designed to be backwards compatible and that is a wide-spread best practice. Keeping this will not require down migrations in your case.

@danizord Because XML requires a dedicated parser for everything, which is hard for arbitrary configuration data that the DBAL may need to construct any connection.

mnapoli commented Mar 24, 2014

@stof Migration SQL should always be designed to be backwards compatible and that is a wide-spread best practice. Keeping this will not require down migrations in your case.

I don't understand how you want to handle down migrations then? Do you suggest to remove the possibility to have down migration at all, or I'm misunderstanding something?


I foresee a lot of resistance to this change, if there hasn't been already. I use down migrations frequently, whilst testing new migrations, rolling back and switching branches. I usually generate my migrations by diff too. Aside from the basic implementation of having migrations at all, these are two of my favourite features, and I'd be surprised if many others don't feel the same.


I agree to the sentiments expressed regarding down migrations and generation from a diff.

On the down migrations: yes, if you just use them and do not think about how to preserve data moving down can leave your with lost data. But it is possible to use down migrations that preserve data if you do the work needed - and those doing that will have a hard time if that is removed. And while the idea of doing migrations up so that it is backwards compatible is nice, just going with the possibility of a safe down migrations works as well.

On generation from a diff: true, not strictly the job of the migrations tool. But do you have any plans for an API that can be used to aid in migration generation? Will the existing code be moved to ORM?


The diff code will be moved to the ORM. But with sql migrations its actually nothing more than php app/console doctrine:schema:update --dump-sql > app/Resources/migrations/v10_DoSomething.sql.

rdohms commented Mar 24, 2014

Having migrations as a incremental value where every increment is valid is a bit of a worrying point when working as a team. Having to keep track of "i have 1.1" or "i have 1.2" might become troublesome, especially since the merging of PRs may not even follow that order.

What are your thoughts on this? I see most migration libraries moving away from this and into hashes or timestamps, so its curious to see this direction being taken.


@rdohms A timestamp is also a valid version number, so you can use that. However using timestamps doesn't prevent you from troubles especially with branches and PRs. Using incremental versions is like a merge conflict, you will get an error and leave the decision to fix to the developer. Its much safer than assuming that two migrations are independent of each other and the order doesn't matter.


@beberlei True, generating SQL migrations is trivial then. Good point!

How would you go about migrating from using Migrations 1.0 to Migrations 2.0? For a standalone project that might be simple (stick to 1.0 or move) but for Frameworks that use/support migrations (like Flow) that is not trivial. Just wondering if you gave that a thought already…


@rdohms wait, i just realized what i find weird about your statement. " I see most migration libraries moving away from this and into hashes or timestamps". Care to mention what libraries you mean?


I find the notion of down to be weird, but what everybody here seems to describe is a revert command, instead of really going down 10 versions. How about allowing to revert certain kinds of migrations by calling something like $migrations->revert($versionNumber); and that only would work if you have a PHP Migration that implements RevertableMigration with a public method revert().?

stof commented Mar 24, 2014

@beberlei The RevertableMigration looks good to me. This would be similar to the current system (it is already possible to mark a migration as non-revertable by throwing an exception, we would do it by not implementing the interface).
When doing this, we should provide a command in the ORM to generate the migration with an option to make it revertable (by generating all the schema diff reverting as this part of the revert can be generated automatically)

maryo commented Mar 24, 2014

+1 for the Interface. I personally leave the down method blank and reload the whole db with Alice when working in dev env.


👍 To the interface.

But how should it work? Currently when I checkout a different branch the code to rollback DB-changes are obviously removed from workspace, so reverting doesn't work. So actually I need to know which changes need to get reverted before I change branches ...


@beberlei Last time we discussed about it we mentioned about possibly reusing some of the concepts implemented as part of data-fixtures 2.0.
I do like what I've seen, but I do see a lot of possibilities on different approaches when considering the solution you had to create to workaround things I've also tackled there.

One good part is around Filtering the migrations already executed. This was also done as Filters on fixtures before execution. Loading could also be expanded to use same concepts of fixtures.
You're also forced into creating a Task\Migrate to solve the migration execution which was solved by an event on data-fixtures. All could be done the same way too.
Driver specific migrations could also rely on the event system to inject dependencies, allowing you to not enforce contract modifications as part of overall execution (something you've done inside of DBALMigration).

We a bunch of very similar situations that we solved differently between the libraries that could be geared towards same concepts on both sides, to simplify user end discrepancies when using multiple libraries of Doctrine umbrella.

Let's try to discuss later this week about possible conversions of both libraries since I think it will be beneficial for everyone.

rdohms commented Mar 25, 2014

@beberlei i was stealing a conclusion i heard on the PHP Town Hall Podcast episode 10, where the Postgres representative was talking about schema migration tools. I do indeed not have a big enough sample to state that.

mkoubik commented Mar 25, 2014

@KingCrunch You could implement MetadataStorage that stores regular and revert SQL to database and Loader that loads it then.

stof commented Mar 25, 2014

@KingCrunch when the migrations are part of the code, this is always the case, even with the current solution. The idea of @mkoubik could indeed work for simple SQL migrations


I'll try that, thanks.

JEDIBC commented Mar 26, 2014

How do you propose to handle migrations of applications which must be compatible with different kinds of databases (mysql, pgsql, mssql, etc...) ?


@beberlei so we still want to target SQL and not go with something like Doctrine\DBAL\Schema\Schema based abstractions?

What made you change your mind? Or is that eventually covered by DBAL migrations?

As @JEDIBC says, software like (for example) PHPBB, which requires being installable/upgradeable on various platforms, would require many different migrations, generated on release per-platform.

If the DBAL platform migrations can handle this (and can be generated from schema diff tools) then this should be fine.

Koc commented Mar 26, 2014

@beberlei please add support of the recursive directories in the migrations. Currently we have too much migrations files in directory. It would be nice separate them like 2014/03/12/1_added_column.sql

mkoubik commented Mar 26, 2014

@Koc 👍

hason commented Mar 26, 2014

@Ocramius 🙏


@beberlei I think the point about Doctrine\DBAL\Schema\Schema based migrations mentioned by @Ocramius is one worth addressing.

We currently use our own fork of migrations that rebased a previous PR to allow this, and it has worked well for us. We did it because we wanted platform independent migrations - we use both sqlite and mysql for some of our apps.

To me it seems like platform independent migrations are critical for some types of apps - and doctrine already has schema abstraction tools, is there a reason we shouldn't use it?

Or, in this new version, is that just another of multiple planned types of migration? Possibly a Doctrine\Migrations\Schema\SchemaMigration in addition to Doctrine\Migrations\DBAL\DBALMigration?

For reference, we took PR #79, and rebased it against master. For us it seems to work fine - though admittedly we haven't been using it -that- long, so we may not have run into some edge cases. Here's our rebased branch if anyone's interested: https://github.com/DavidMikeSimon/migrations/network

stof commented Mar 26, 2014

@evillemez using Doctrine\DBAL\Schema\Schema to execute the migration means that you cannot perform additional changes on the data in the middle of the schema changes. This makes it impossible to migrate reliably. It is exactly the same than running doctrine:schema:update in the ORM.

The proper way to have cross-platform migrations is not to use the Schema classes (these classes cannot describe a full migration) but instead to write PHP code using the DB platform at execution time to generate the SQL instead of doing it at generation time (the alternative being to generate several sets of migrations, but it is not really a cross-platform way).

stof commented Mar 26, 2014

and if you want to know an "edge" case where this breaks, it is really simple: add a new non-nullable field in our table with a unique constraint. There is only 2 ways to perform such schema change:

  • ensure your table is empty before doing the change (obviously not a good idea for a prod migration)
  • update rows after adding the field and before adding the unique constraint so that all values in the field are unique

@stof This strikes me as being a problem with the way Schema migrations are executed. Why not allow migrations to specify when Schema changes are to be applied?

stof commented Mar 26, 2014

@DavidMikeSimon please read again what I described. It requires adding custom queries (impossible to be generated by Doctrine as it does not know your data) in the middle of the schema changes


@stof I believe that I read you correctly. Your example case would naively be done with schema code like this:

$table = $schema->getTable("people");
$this->addSql('UPDATE people SET nickname = name');

At the moment this does not work because the changes to Schema\Table are all applied (effectively) at once; they modify an in-memory schema state, which is applied in a single step to the database, and anything added with addSql() happens after that.

One way to deal with this would be to treat statements like addColumn as actual steps to be applied in order, so that the naive way actually works. However, this would be a significant change to the way Schema works, and so would take a lot of work to implement.

The other (and I think simpler) way to deal with it would be to allow Schema changes to be applied mid-way through a migration, with perhaps something like this:

$table = $schema->getTable("people");
$this->doSql('UPDATE people SET nickname = name');

This would essentially just be an easier-to-read equivalent to the current possible approach of doing the above in three separate migrations.

stof commented Mar 26, 2014

@DavidMikeSimon You are doing some modifications on 2 unrelated objects, and one of them is not responsible for triggering queries but for representing a given schema (the SQL queries are coming from the SchemaComparator, not from the Schema). So it is logical that the order of queries is not retained.

what you are suggesting in the second case is a different purpose for the Schema class itself (your class is not representing a schema anymore. It represents a schema change). We could build such a tool, but it would not be a Schema anymore


@stof With controlled application i.e. my "other way to deal with it" that I mentioned above, a Schema would still be a Schema. As I said above, it would be effectively the same as what one can do now with several migrations.


@Ocramius The introduction explains why Schema based migrations suck. Its not determenistic. Also the ordering problem as discussed in comments below exists, which is totally confusing.

My plan for multi vendor apps is to seperate the schemas in folders named by the platform. Its not perfect, but its easy and simple, which is what i am aiming for in a migration tool. The other solution is to build PHP based migrations and make switches over $connection->getDatabasePlatform()->getName() in the code, which is what you can do at the moment in Migrations 1 as well.

Schema is indeed a good tool for generating diffs, but as Stof explained, there are many use cases where the way it works generating everything without context of the data is not possible. That is why using them for one time generation (and possible adjustments) is way better than using them at runtime.

@DavidMikeSimon what you describe is something that a tool called Liquibase does. If you want that approach feel free to use that tool. Since its using an abstraction (XML) there is no sense in copying that tool to PHP. You can also write with very few code a visitor for the SchemaDiff object of Doctrine to convert to a first draft for a liquibase migration. I don't want to waste time rebuilding something that already exists though.

I'd happily abandon Migrations for one of the Java based tools. However there are catches. Liquibase I find is too much abstraction, I want to be very close to the actual SQL that gets executed. For the last 2 years i have been working with DBDeploy excessivly, however it has a creepy way of handling undos and doesnt allow migrations in code, only in SQL files. Both of which i found problematic. Then I found FlywayDB (http://flywaydb.org/documentation/migration/ ) recently which is exaclty what i expected of a migration tool, simple and robust. However the migrations in code are written in Java. So a tool that works in PHP would be something useful. And here we are..


@Ocramius The introduction explains why Schema based migrations suck. Its not determenistic. Also the ordering problem as discussed in comments below exists, which is totally confusing.

Makes sense to me. I just thought we were going more in the liquibase direction since the last time we talked about migrations. I'm fine with either way: migrations are app-specific anyway.

stof commented Mar 27, 2014

@beberlei I find the proposal good, if we add the support of revert discussed previoously. It would be great to be able to write SQL-based revertable migrations too (creating a class storing the SQL in a string and executing just to be able to have the revert SQL would work, but adds unnecessary garbage IMO)


@beberlei It's better to have a PHP tool when working in a PHP ecosystem, because you can then more easily integrate that tool into other parts of the workflow. For example, our shop has a custom fixture generator which relies upon being able to abstractly examine and run Doctrine migrations.

Additionally, I don't think it would be that much of a change to add an apply() method to Migrations that makes my above example work. If I wrote a PR that did this, would you (@stof and @beberlei) accept it?


+1 stunning(,) profound, simple and wow!
As lousy down migrations are, as handy they are in automated up-down-up test.

some naming trivia:

maybe the rule "is sortable" is enough and there is no need for a format at all?

this seems not be configurable?

how about Metadata?

MigrationInfo $migration
absolutely correct but may be less verbose?

repetitive DBAL needed?

Migrations and MigrationSet are completely different, yet the names sound alike.
Is there a better name for one of those?

absolutely need to try this... Thank You!


I'm happy and trust everyone here, as long as generating the diff is still easy. Right now, it's effortless: just run one command, not even any arguments. That's really great. I saw the example with running doctrine:schema:update and dumping it into a migration file. That's easy, but a command that does that for you (and helps you name the migration) would be even better. I realize it won't be part of this lib - but it's my only concern :).

Thanks and cheers!


In my opinion a separate command only to redirect the output is too much. Maybe an additional parameter dump [-o|--output filename] can make sense, but then I again ask myself, why this should better than a simple dump > filename

flip111 commented May 12, 2014

@KingCrunch and @Stof
IMO migrations should be stored with the application so that the latest version of the application also has access to the latest version of the migration (database). To revert back to an older version, first check out a new-enough version then revert the database, then checkout an older version of the application.

For safety doctrine migrations should check (if it doesn't already) if the migrations it has are new enough to revert back the version of the database it's working on.

What did you mean with

because it proved to be a source of bugs and when executed with reproduceability in mind

in the opening post? Could you name some examples?

Also when not being very familiar with all the possible migration tools it's difficult to know if Doctrine migrations fits your need. Now that Doctrine migrations is not moving towards the direction of Liquibase, where is it moving to?? What will be supported in the end and what not? Or is this still under debate?

Ideally i would like to have a tool in PHP that handles schema and data migrations well. I would imagen it doing a procedure like:

  1. Rename old tables/columns (suffix _old)
  2. Create new tables/columns (but all columns with allow NULL and no constraints)
  3. Write your own script to move data around. (you can use the old columns/tables)
  4. Remove the old data (dump data to disk)
  5. Apply column NOT NULL and constraints.

When using native SQL the migration should supply a list of platforms that it supports.

About step 4:
When moving up or down in schema data may be lost. So it's useful if you can read those back from files. These should not be in version control with the application because the app can run on different databases (with different data).

I think there is a need for a tool like this, but maybe it's outside of the scope of Doctrine Migrations ??

stof commented May 12, 2014

MO migrations should be stored with the application so that the latest version of the application also has access to the latest version of the migration (database)

I think you misunderstood what I was saying. In case you have 2 migration v1 and v2 written and you allow your code to use the EntityManager inside the execution of v1, you will get a big issue if your are migrating a project from v0 to v2 directly (because you haven't deployed on this server between the creation of v1 and v2 for instance): at the time of executing migrations, the code of your application will be at v2. So executing v1 will fail in your ORM.
Having to deploy twice to have the code of v1 first would be a huge pain (especially if the guy deploying does not know how many non-executed migrations there is, and at which commit they have been introduced exactly). On the other hand, SQL migrations don't suffer from this issue, because they won't depend on the PHP code living in your project.

I think there is a need for a tool like this, but maybe it's outside of the scope of Doctrine Migrations ??

This indeed look like a different tool

flip111 commented May 12, 2014

Hi Stof,

Fair point about the Entities, i considered this as well, but i didn't know you were talking about that. It's not really clear at the moment if one should work with 1. native sql 2. schema classes or 3. real entities in Doctrine Migrations. I don't think using real entities is a good idea really. But if you want you could try to generate those classes on the fly, write them to file, and then require them. I don't really see a good use case for it now. If real classes are THAT important for the migration they should be part of the migration themselves!

P.S. Still like to know what Doctrine Migrations should become in the future (scope)


@beberlei @stof Anything one like me can do to help? 😄


@KingCrunch we're discussing the possibility of merging fixtures and migrations into a single project.
I was supposed to make a simple attempt to change how Fixtures 2.0 deal with loaders and be able to import SQL data files.

I'm tied to a massive deployment at the moment which was supposed to go live 2 weeks ago. I expect this to take another week. Once it is finalized, I'll be back to this.

acrobat commented Jun 29, 2014

You guys should also take a look at the way sqitch handles database migrations. They use a .plan file to describe changes and add the possibility to add requirements to a certain change, so the script knows it depends on other changes first

Dependency resolution

Database changes may declare dependencies on other changes -- even on changes from other Sqitch projects. This ensures proper order of execution, even when you've committed changes to your VCS out-of-order.

No numbering

Change deployment is managed by maintaining a plan file. As such, there is no need to number your changes, although you can if you want. Sqitch doesn't much care how you name your changes.

Iterative Development

Up until you tag and release your application, you can modify your change deployment scripts as often as you like. They're not locked in just because they've been committed to your VCS. This allows > you to take an iterative approach to developing your database schema. Or, better, you can do test-> driven database development.

stof commented Aug 18, 2014

@beberlei what is the status of this rewrite ?




@stof We discussed merging efforts with fixtures to use common code, but development staled.

Meanwhile i stumbled accross https://speakerdeck.com/theory/sane-database-change-management-with-sqitch which is new input for me on how to solve the problem that looks good. As its the first other tool that doesn't require Java+Ant, but Perl (which is abundant on Linux servers) i am considering if it would be better advice to suggest using this to Doctrine users.


@beberlei I quickly checked these slides and don't like it much. I like comfort of command line and generating migrations based on differences between entities and database.

Do you suggest to completely abandon this package and use Sqitch?
Maybe I can't imagine how difficult it is to maintain this package.


I think this library should be released as 2.0 as is and fixtures kept separate. I have seen wheel reinvention https://github.com/pagekit/framework/tree/master/src/Component/Migration and elsewhere just because there is not a package like this with some degree of visibility. It brings good practices and will get some love once it is announced. Also sqitch is good but I think for simple cases can be overkill (and does not give the flexibility/familiarity of php for newcomers as would a simple linux-like tool/package in PHP land). This library also clears a lot of doubts that many have about the earlier magic on migrations.


having reread the thread yet another time, I can emphasize the need for a PHP library since for this use cases where people do plugins like in wordpress we would want to run migrations with our plugins, and no way you will run this with perl. The other argument about whether down migrations are still ok good or not can be dealt with within the library itself.

I am using it and can add a command and some service provider if need be like here http://www.craftitonline.com/2014/09/doctrine-migrations-with-schema-api-without-symfony-symfony-cmf-seobundle-sylius-example/ will you take it in @beberlei ?

@acrobat acrobat referenced this pull request Oct 8, 2014

Time for a stable release? #120


This looks as abandoned approach (WIP in over year and half) and can be probably closed.


I keep it to be able to look at it simply


You can see closed PRs as well.



Koc commented Nov 27, 2015

@mikeSimonson have you any plans to start work on 2.0 version? maybe based on this PR


@Koc There is work on a v2. Based on https://github.com/baleen/migrations.
But we have still a bit of work to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment