Database Migrations

Google for DoctrineMigrationsBundle. To install it, copy the composer require line. But again, we don't need to have the version - Composer will find the best version for us:

composer require doctrine/doctrine-migrations-bundle

While Jordi is preparing that for us, let's keep busy. Copy the new statement from the docs and paste that into the AppKernel class:

56 lines app/AppKernel.php
... lines 1 - 5
class AppKernel extends Kernel
public function registerBundles()
$bundles = array(
... lines 11 - 20
new Doctrine\Bundle\MigrationsBundle\DoctrineMigrationsBundle(),
... lines 22 - 23
... lines 25 - 33
... lines 35 - 54


We already know that the main job of a bundle is to give us new services. But this bundle primarily gives us something different: a new set of console commands. Run bin/console with no arguments:


Hiding in the middle is a whole group starting with doctrine:migrations. These are our new best friend.

The Migrations Workflow

Our goal is to find a way to safely update our database schema both locally and on production.

To do this right, drop the database entirely to remove all the tables: like we have a new project.

./bin/console doctrine:database:drop --force

This is the only time you'll need to do this. Now, re-create the database:

./bin/console doctrine:database:create

Now, instead of running doctrine:schema:update, run:

./bin/console doctrine:migrations:diff

This created a new file in app/DoctrineMigrations. Go open that up:

29 lines app/DoctrineMigrations/Version20160207083131.php
... lines 1 - 10
class Version20160207083131 extends AbstractMigration
public function up(Schema $schema)
// this up() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");
$this->addSql("CREATE TABLE genus (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, sub_family VARCHAR(255) NOT NULL, species_count INT NOT NULL, fun_fact VARCHAR(255) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB");
public function down(Schema $schema)
// this down() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");
$this->addSql("DROP TABLE genus");

Check this out: the up() method executes the exact SQL that we would have gotten from the doctrine:schema:update command. But instead of running it, it saves it into this file. This is our chance to look at it and make sure it's perfect.

When you're ready, run the migration with:

./bin/console doctrine:migrations:migrate

Done! Obviously, when you deploy, you'll also run this command. But here's the really cool part: this command will only run the migration files that have not been executed before. Behind the scenes, this bundle creates a migrations_versions table that keep strack of which migration files it has already executed. This means you can safely run doctrine:migrations:migrate on every deploy: the bundle will take care of only running the new files.


You can run migration in reverse in case something fails. Personally, I never do this and I never worry about down() being correct. If you have a migration failure, it's a bad thing and it's better to diagnose and fix it manually.

Making Columns nullable

In newAction(), I'll add some code that sets fake data on the subFamily and speciesCount properties. But, I'll keep funFact blank: maybe some genuses just aren't very fun:

76 lines src/AppBundle/Controller/GenusController.php
... lines 1 - 11
class GenusController extends Controller
... lines 14 - 16
public function newAction()
$genus = new Genus();
$genus->setName('Octopus'.rand(1, 100));
$genus->setSpeciesCount(rand(100, 99999));
... lines 23 - 28
... lines 30 - 74

Ok, head over to /genus/new to try it out! Woh, a huge explosion!

Integrity constraint violation: 1048 Column fun_fact cannot be null

Here's the deal: Doctrine configures all columns to be required in the database by default. If you do want a column to be "nullable", find the column and add nullable=true:

81 lines src/AppBundle/Entity/Genus.php
... lines 1 - 10
class Genus
... lines 13 - 34
* @ORM\Column(type="string", nullable=true)
private $funFact;
... lines 39 - 79

Creating Another Migration

Of course, just because we made this change doesn't mean that our table was automatically updated behind the scenes. Nope: we need another migration. No problem! Go back to the terminal and run:

./bin/console doctrine:migrations:diff

Open up the new migration file: ALTER TABLE genus CHANGE fun_fact to have a default of null. This look perfect. Run it with:

./bin/console doctrine:migrations:migrate

So easy! Refresh the page again: no errors. Migrations are awesome.

Leave a comment!

  • 2017-05-31 Diego Aguiar

    Good day Céline Ollagnier

    I'm really happy that you could find and fix your problem :)
    but, if you really want to go to the bottom of this problem and find the absolute reason, remove completely your vendor's directory, and your composer.lock file, then run "composer install" and try again to run the migrations, if it doesn't work, it's because you really need to "update" your dependencies, and I believe it would be something related to windows 10, but if it works, you were right, something during installation silently failed


  • 2017-05-31 Céline Ollagnier

    Hi Diego.
    I've removed and installed again migration, it didn't worked, but I updated my composer and all the dependencies (again) and now it's OK.
    I don't know why and yes, I could have used the "updated" method but I wanted to try this and understand my problem. So it was probably a bug during an installation or update.
    Gracias Diego :)

  • 2017-05-30 Diego Aguiar

    Hey Céline Ollagnier

    Your file look's good to me, so there is not the problem. I would suggest you to first try running:

    $ composer update doctrine/doctrine-cache-bundle --with-dependencies

    Maybe there is a bug in your current installation, and if that doesn't works, remove it completely and re-install it again, I hope that fix your problem :)

    Fue un placer ayudarle (I never took French :( )

  • 2017-05-29 Céline Ollagnier

    I'm from France, it's 9 PM here. So...
    1. I've tried again from /bin/console doctrine:database:drop --force
    and... same thing.
    2. I'm always writing the full command to get used to it with an S
    3. Well... If by migration you say the Version... here you go

    abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', 'Migration can only be executed safely on \'mysql\'.');

    $this->addSql('CREATE TABLE genus (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, sub_family VARCHAR(255) NOT NULL, species_count INT NOT NULL, fun_fact VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');

    * @param Schema $schema
    public function down(Schema $schema)
    // this down() migration is auto-generated, please modify it to your needs
    $this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', 'Migration can only be executed safely on \'mysql\'.');

    $this->addSql('DROP TABLE genus');

    Last solution... Take off the bundle to make a new installation or perhaps try to update it?

    Thanks for your help, oops! Gracias por su ayuda (memories of High school spanish ^^)

  • 2017-05-29 Diego Aguiar

    Hey Céline! From which part of Europe are you ? I'm from Mexico :)

    Hmm, look's like everything works just fine but migrations, lets try a few things:

    1) Delete your migration file and generate / run again.

    2) Try running the full command name "doctrine:migrations:migrate" with an "s" in migrations.
    Symfony by default try to match any registered command with your input, so if you only write "doc:mig:mig" symfony will run "doctrine:migrations:migrate", I think there may be the problem.

    3) If nothing of this works, let me check the code inside your migration file


  • 2017-05-29 Céline Ollagnier

    Hi Diego (I'm lucky it's daytime for you -European time here- :) )
    I can create a base, I just try and well It said that aqua_note is already existing (so ok it's working) and yes I've got a migration_versions table. But my base is empty except this table.
    As Ryan said I didn't put a version number and let the installation do its job. My composer.json says... "doctrine/doctrine-migrations-bundle": "^1.2" and for symfony "symfony/symfony": "3.2.*"

  • 2017-05-29 Diego Aguiar

    Hey Céline Ollagnier

    Let's track down this problem!

    Can you run any other command successfully ? and specially any other doctrine's command ? e.g. doctrine:database:create
    Which version of the bundle did you install and what's your symfony version ?
    In your database can you see a "migration_versions" table ?


  • 2017-05-29 Céline Ollagnier

    I've installed the migrations bundle, done the diff, it's OK I've got my file, but when I do the php bin/console doctrine:migration:migrate (I'm on Win 10), well... I've got only an "Application Migrations" sentence in the console and that's all >.<
    The script is working (well at least I know it from the console) showing me the blinking cursor.
    I've tried to let it run for more than 10 minutes but nothing happened (and debug isn't working). The same if I use the name of the file I want to migrate.
    Any idea?

  • 2017-04-28 jian su

    Great! Thank you!

  • 2017-04-27 Victor Bocharsky

    Hey Jian,

    You can do it with the Symfony console command:

    $ bin/console doctrine:migrations:execute YYYYMMDDHHMMSS --down

    YYYYMMDDHHMMSS - is your migration you want to downgrade.


  • 2017-04-27 jian su

    Hi if I want to roll back to the previous version. how do I do that?

  • 2017-04-25 Victor Bocharsky

    Hey Jian,

    You can add "DELETE" queries to your migrations as well, but only when it's on purpose, i.e. you have to remove the table or column locally AND on production. The important is how do you start using migration. If you start using migrations from scratch of your project - I don't see any problems. But if you start using migrations on already existent project which already has production DB with real data - then you should start writing migrations locally on the same state which your production DB has ;)


  • 2017-04-25 jian su

    Thank you so much! it make total senses now!. so the take way here is Don't ever do remove tables on local and then uploads to production. Do it when it is adding columns!.

  • 2017-04-24 Victor Bocharsky

    Hey Jian,

    It depends! Let's look at some example: you have locally and on production the same code with synced DB schema and everything works fine. Then you want to start using migrations. You did some schema-related changes locally (for example, add new column) and create a migration. Then this migration you can safely run on the production, but right after when the migration was created you have to validate queries in it - they should be safe. In my example you should have one single query, something like "ALTER TABLE table_name ADD column_name" and that's it. So obviously this query is safe enough on production.

    But if you decide to start using migration and will remove locally all the tables inside the DB and try to add them with migrations - I think you see that this won't be safe to run on production ;)


  • 2017-04-23 jian su

    Good morning! just a question. If the production DB is not version control, I mean never ran any migration before. Now I decide to do it now. and run >php console doctrine:migrations:migrate. what would happen? Is it safe to do that? I really want to know. Thanks

  • 2017-04-20 Julia Shishik

    Thank you! Yes! You are right!

  • 2017-04-19 Victor Bocharsky

    Hey Julia,

    I suppose it didn't work before because you type "nullable=true" but didn't execute the migration (or run "bin/console doctrine:schema:update --force"). But eventually, this update was applied to your DB schema and it works now, so it's difficult to say after what actions it was applied. When you change your metadata, like adding "nullable=true", etc. you can check your current DB schema state with "bin/console doctrine:schema:validate". It will show you whether changes were applied or no. And of course, don't forget to clear the prod cache if you want to test it with prod environment.


  • 2017-04-18 Julia Shishik

    My solution to the problem:
    private $subFamily;

    * @ORM\Column(type="integer", nullable=true)

    private $speciesCount;

    * @ORM\Column(type="string", nullable=true)
    nullable=true in the $subFamily and $speciesCount;
    I don't understand why, but this works!!

  • 2017-04-18 Victor Bocharsky

    Hey Julia,

    Looks like you're trying to execute INSERT query *before* making species_count column NULL by default. I think you just need to put your migration query about `nullable=true` upper, at least right before the INSERT query. Then it will work. If you still have problems - could you show me your migration queries I'll try to help you?


  • 2017-04-18 Julia Shishik

    Good morning! Please help me, I have an error after type nullable=true and migration :
    An exception occurred while executing 'INSERT INTO genus (name, sub_family, species_count, fun_fact) VALUES (?, ?, ?, ?)' with params ["Octopus91", "Octopodinae", null, null]:

    SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'species_count' cannot be null
    500 Internal Server Error - NotNullConstraintViolationException
    2 linked Exceptions: PDOException » PDOException »

  • 2017-03-15 Victor Bocharsky

    Hey Peter,

    For me migrations works fine on the latest Symfony version, so probably you have some misconfiguration. I suggest you to update your composer.json file according to the latest changes in composer.json. Look closer to the dependency versions in it. Then manually remove cache folders and do "$ composer update".

    Btw, what OS do you use? Are you on Windows? What's your PHP version? And what's very important in your case, ensure you specify the correct platform PHP version on this line: . But if you change this line - you have to do all my instructions above one more time.


  • 2017-03-15 Peter Tsiampas

    Hey Victor

    Yeah, I tried that and it didn't fix it for some reason. Not sure why it looks like it's a known problem but a fix is still pending.
    If you can recommend a way to get migrations working from a fresh install of Symfony that would be great.


  • 2017-03-14 Peter Tsiampas

    I know it's been a month, busy building Symfony apps :) Nope didn't work, I thought I had fixed it :(.

  • 2017-03-08 Tony C

    Nope. That was the first (and second) thing I tried.

    Just double-checked again. Really just looks like `doctrine_migrations` must either not be getting the defalut setting, or are getting overwritten somewhere. No worries, dropping the default from their documentation, straight into the config.yml, did the trick. I'll figure out the rest later. :)

  • 2017-03-08 weaverryan

    Hey Tony!

    Interesting! You should not need to specify *any* configuration to use the bundle - I just double-checked their code (I was wondering if there was a recent change). Now, if you *do* decide to add a doctrine_migrations key in config.yml, then I believe that suddenly you *are* required to have the dir_name, namespace and table_name values. But it should also be legal to have *no* doctrine_migrations config at all.

    So, does it work if you remove this configuration entirely from config.yml?


  • 2017-03-08 Tony C

    When running `doctrine:migrations:diff` I ran into an issue where the doctrine_migrations defaults were not defined, resulting in the following error:
    The parameter "doctrine_migrations.dir_name" must be defined.

    Fixing it only requires a small config.yml adjustment, and clearing cache:

    # app/config/config.yml
    dir_name: "%kernel.root_dir%/DoctrineMigrations"
    namespace: Application\Migrations
    table_name: migration_versions
    name: Application Migrations
  • 2017-02-13 Victor Bocharsky

    Hey Peter,

    Could you try to run "$ composer update"? Does it fix the problem? It's very looks like the "ocramius\proxy-manager" package has incompatible version with PHP 7 and "composer update" should fix that.


  • 2017-02-11 Peter Tsiampas

    I have had a hunt around for a solution but I can't find one, I am getting this error:

    > Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap
    > Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache

    Fatal error: Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: Type error: Argument 2 passed to ProxyManager\Generator\Util\ProxiedMethodReturnExpression::generate() must be an instance of ProxyManager\Generator\Util\ReflectionMethod, instance of Zend\Code\Reflection\MethodReflection given, called in J:\phpStormProjects\keystrokes\vendor\ocramius\proxy-manager\src\ProxyManager\ProxyGenerator\LazyLoadingValueHolder\MethodGenerator\LazyLoadingMethodInterceptor.php on line 72 in J:\phpStormProjects\keystrokes\vendor\ocramius\proxy-manager\src\ProxyManager\Generator\Util\ProxiedMethodReturnExpression.php:33

    Now the Server won't run, and it only happens when I install, it seemed very similar to another error posted which I tried the solution but it didn't work.

    I have done a completely fresh install of symfony as directed, then just added the database migration bundle.

    Can anyone give me advice on this?

  • 2017-01-19 Victor Bocharsky

    OK, as I understand, when you run migrations - the Genus table will not created, right? Do you have any errors in the console? Actually, if you modify the migration *after* it was executed - it will be skipped the second time. So in this case you need to rollback it and then run migrations again:

    $ bin/console doctrine:migration:execute 1234567890 --down
    $ bin/console doctrine:migration:migrate

    I hope it helps you.


  • 2017-01-19 Д. Энхбаяр

    Sorry poor English language ..
    "y" and "n" Results out of the same

  • 2017-01-18 Victor Bocharsky

    Yo Д. Энхбаяр ,

    You should type "y" (yes) instead of "n", i.e. you should agree with this warning. It's difficult to understand what is your question here. Could you explain it?


  • 2017-01-18 Д. Энхбаяр


    $ ./bin/console doctrine:migrations:migrate

    Application Migrations

    WARNING! You are about to execute a database migration that could result in schema changes and data lost. Are you sure you wish to continue? (y/n)n
    Migration cancelled!

    Databases only migration_versions create done Genus table not create symfony 3.2.1

  • 2016-10-30 Max

    Well, that sounds reasonable :) Thank you very much!

  • 2016-10-30 weaverryan

    Yo Max!

    Yea, amazingly, under many (but not all) situations, Doctrine DOES turn notice the renaming and turn it into a CHANGE query. That's pretty cool :). So, you're 100% right about doctrine:migrations:diff and doctrine:schema:update being equally perfect or equally flawed in the SQL they generate: if one somehow generates some SQL that isn't quite right, then they both will generate that (they generate the SQL using the same engine).

    The big advantage of migrations is when you deploy your app to production *and* when you have those not-so-common cases where the generated SQL isn't perfect. Let me give you an example: suppose I'm adding a new column to Event, e.g. slug (URL-safe, unique string), and I give it unique=true. The generated SQL for that will look totally fine. But when I run it, it'll likely fail: if there are any Event objects already in the database, then they will all be given a blank slug... which of course isn't unique :). The fix, would be no:

    A) NOT make the field unique, and generate a migration for just the new (non-unique field)
    B) Add a second migration by hand (or update the first) that does some sort of a *data* migration - calculating and setting unique slug values on each row
    C) Make the slug field unique again, and generate a migration for *just* the unique change

    Now, if you deploy to production and run doctrine:migrations:migrate, that entire, validated & safe history is replayed. Obviously, that can't be done with doctrine:schema:update.

    I know people that deployed and used doctrine:schema:update on production for a long time. It will work 99% of the time, but eventually it won't :). The big difference with migrations is that it actually allows you to *change* the SQL to fix whatever problem it has, and doctrine:schema:update doesn't give us that chance.


  • 2016-10-28 Max

    Hey Victor!

    Thank you very much for your reply. How exactly are migrations solving that problem? When I run doctrine:migrations:diff the SQL says (after adding a new property and changing an old one to a new name):

    $this->addSql('ALTER TABLE yoda_event ADD test VARCHAR(255) NOT NULL, CHANGE details dummy LONGTEXT NOT NULL');

    doctrine:schema:update --dump-sql creates the same statement:

    ALTER TABLE yoda_event ADD test VARCHAR(255) NOT NULL, CHANGE details dummy LONGTEXT NOT NULL;

    So besides of creating a history of my database changes, where is the difference of running a checked (via --dump-sql ) doctrine:schema:update and a migration checked via looking at the php?? A doctrine:migrations statement could be equally flawed as a doctrine:schema:update statement, so both could possibly "destroy" parts of my production database.

  • 2016-10-28 Victor Bocharsky

    Hey Max,

    Migrations allows you to automate updating DB in production safely (of course, you should double check all the new migrations to ensure that they contain safe instructions). The most common example I know is that you can rename entity's property, i.e. rename column in DB. But if you blindly run doctrine:schema:update - Doctrine will just add a new column and drop existent one, i.e. you will lose your data! Probably, It's not important for development - you can just reload your fixtures again, but it's very critical for production. And migrations solve this problem for you. I mean, doctrine:schema:update command isn't perfect, and sometimes you need to do some extra work. So if you write a good migration - you can safely execute it on production server without losing your data.

    What about downgrading - it's a very rare cases. Btw, we don't care much about it on KnpU. If something went wrong - we manually execute some SQL commands to return DB in the previous state based on upgrading commands and using "doctrine:schema:update --dump-sql" for help. But probably in some projects using downgrading makes sense, especially if project under the active development and has a big team.

    I hope it clearer for you now.


  • 2016-10-26 Max

    Actually I don' really got the point why using migrations is so useful... Just for seeing the SQL code before you run it could be solved differently without a external file.
    Furthermore you say that it just runs the newly generated migration files. But wouldn't do doctrine:schema:update do basically the same - applying only my NEW changes (as the old ones are already mirrored in the database) using the various ORM annotations to the database by looking at it, substracting the status quo from the entity-annotation-status and showing my the necessary changes in SQL language?

    I got the feeling that the migrations create something like an version control system for the database schema as there's also the down function in the migration file. But is there a real-life scenario where you would use that - downgrading your database to a previous state?

    As always: thanks in advance!

  • 2016-10-19 Shairyar Baig

    Many thanks Ryan, I tried this and it seems to work pretty well.

  • 2016-10-16 weaverryan

    Hey Shairyar!

    Yep, that's exactly right! The Doctrine migrations library keeps a migration_versions table in your database (both locally and on production - basically inside any database where the app is run) that keeps track of what migrations were and were not run. So, the flow looks like this:

    1) [Local] Make some entity changes
    2) [Local] Run doctrine:migrations:diff to create the new file in app/DoctrineMigrations/
    3) [Local] Run doctrine:migrations:migrate to execute that file locally and record that this migration file has been executed in the migration_versions table (of your local database).

    ... then eventually you copy ALL files, including the migration files to production. At this point, suppose that you have actually created *3* new migration files since you last deployed your files.

    4) [Production] Run doctrine:migrations:migrate. This will look at the migration_versions table on your *production* database and notice that there are *3* new files in your app/DoctrineMigrations directory that have not been executed against that database yet. Then, it will execute those 3 migrations and record 3 new rose in the migration_versions table.

    So, really, running doctrine:migrations:migrate should just be part of your deploy process - I usually do it right after copying my files and clearing cache.


  • 2016-10-16 Shairyar Baig

    Hi Ryan, I am a bit confused.

    I have two copies of the code, one sitting locally on my laptop and another a production copy which is uploaded via ftp sitting on a server. So if I run the command /bin/console doctrine:migrations:diff on my laptop this will create a migration file locally, do I then upload that file on the server and run the command /bin/console doctrine:migrations:migrate there?

  • 2016-09-25 weaverryan

    Hey Pete!

    Over the weekend, I finally discovered the problem: a backwards-compatibility break in PHP 7.1. Some of the guys in charge of these very libraries that are involved are working to try to revert it before 7.1 is fully released.

    Here's more info: And yes, there literally is a ? being added somewhere internally, and it's (at least in theory) by design.


  • 2016-09-24 Peter Stephens

    "composer upgrade" did upgrade a few packages, but did not fix the problem. I downgraded to PHP 7.0 and it works fine. I will stick with that as I have no real reason to use PHP 7.1. Thanks for the tips. I learned a lot.

    - Pete

  • 2016-09-21 Victor Bocharsky

    Hm, probably I was wrong about package, Could you try to update all your dependencies to the latest versions with: $ composer update?

  • 2016-09-21 Peter Stephens

    Looks like I am already at 3.0.4

    $ composer show -i | grep -i zend
    You are using the deprecated option "installed". Only installed packages are shown by default now. The --all option can be used to show all packages.
    zendframework/zend-code 3.0.4 provides facilities to generate arbitrary code using an object oriented interface
    zendframework/zend-eventmanager 3.0.1 Trigger and listen to events within a PHP application

  • 2016-09-21 Peter Stephens

    Oh cool! I will try that. Thanks Victor.

  • 2016-09-20 Victor Bocharsky

    Hey Peter,

    IIRC, it was a bug which fixed in the newest version of this library. What version of zendframework/zend-code do you use? Please, try to update zendframework/zend-code to the latest available version. I see the latest version is 3.0.4 now. You could try to update only this package with next command in console:

    $ composer update zendframework/zend-code


  • 2016-09-20 Peter Stephens

    Thanks for tip, but no dice. I have PHP7.1 on Ubuntu. It probably has to do with that version as the other post states.

    I did find the regex expression in the file, "vendor/zendframework/zend-code/src/Generator/TypeGenerator.php" and can see that it is from the "fromTypeString" function. I can also see that "fromTypeString" is getting called from "setType" in "vendor/zendframework/zend-code/src/Generator/ParameterGenerator.php". I kinda lose it from there.

    Do you think the "question mark" at the beginning of the dump is an indicator or what it is actually complaining about? I went to "" and used the "preg_match" to look at the regex and it matches "Doctrine\DBAL\Schema\SchemaConfig", but not "?Doctrine\DBAL\Schema\SchemaConfig".

    - Pete

  • 2016-09-19 weaverryan

    Hey Peter!

    Wow, I don't understand that either! And when I googled for it, I could *also* only find that same *one* like on the Internet about this :/. I'm not sure if it matters, but what version of PHP are you running?

    I would try this one thing: delete your entire vendor/ directory and use composer to re-install. You should *not* need to do this... but this is a really strange error :).

    rm -rf vendor/
    composer install

    Let me know if that works, or if there's anything else that may be non-traditional about your setup.


  • 2016-09-18 Peter Stephens

    Hey guys, When I try to run "php bin/console doctrine:migrations:migrate" I get,

    Migrating up to 20160918154810 from 0
    Migration 20160918154810 failed during Pre-Checks. Error Provided type "?Doctrine\DBAL\Schema\SchemaConfig" is invalid: must conform "/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*(\\[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*)*$/"

    Provided type "?Doctrine\DBAL\Schema\SchemaConfig" is invalid: must conform "/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*(\\[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*)*$/"

    doctrine:migrations:migrate [--write-sql] [--dry-run] [--query-time] [--allow-no-migration] [--configuration [CONFIGURATION]] [--db-configuration [DB-CONFIGURATION]] [--db DB] [--em EM] [--shard SHARD] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command> [<version>]

    I did find this,

    However I don't really understand what the writer is implying.

  • 2016-08-12 claire

    It worked and thank you again for explaining what was happening when you run composer. Really interesting to find out about this feature 'incenteev parameter handler'.


  • 2016-08-11 weaverryan

    Hi Claire!

    Ok, let's figure this out :). First, the error isn't coming exactly from running composer require. But instead, after compose require finishes running, Symfony does some final clean up (e.g. it clears its own cache). When *this* is happening, we're getting this error.

    And at first, the reason is really simple: somewhere (probably config.yml) you are referencing %database_path%. But, this is *missing* from your parameters.yml file. It's very likely that you *did* have database_path in parameters.yml, until you ran composer require. You see, there is an extra process that runs whenever you run composer require/update/install. This process - called the "incenteev parameter handler" - compares your parameters.yml.dist file and your parameters.yml files. If you are missing something from your parameters.yml file (as compared to the .dist file) it will ask you for a value and fill it in for you. BUT, if you have some *extra* keys in parameters.yml (like database_path) that you forgot to add to your parameters.yml.dist file, it will actually remove them from parameters.yml! I've always disliked that feature, but I bet this is what's happening.

    The fix:

    - re-add database_path to your parameters.yml file
    - also add database_path to parameters.yml.dist (it can be set to any value - it just needs to be there).

    The next time you use Composer, it won't remove your database_host parameter. Btw, you can see where this "magic" parameters handler thing is registered - if you look at your composer.json file, under post-install-cmd/post-update-cmd section:

    Let me know if that fixes it! Cheers!

  • 2016-08-11 claire

    Hi Ryan,

    I am trying to install the require doctrine/doctrine-migrations-bundle. However I keep getting this back : [Symfony\Component\DependencyInjection\Exception\ParameterNotFoundException]

    You have requested a non-existent parameter "database_path". Did you mean one of these: "database_host", "database_port", "database_name", "database_user"?

    I've check my parameters.yml.dist and parameters.yml and neither have the key of database_path. Not really sure where the error is coming from.


  • 2016-07-04 Dan Costinel

    Still some months left for my current deal with the hosting company. And yeah, I'm taking into consideration to change the hosting provider. I thought there might be other solutions to my problem... Anyways, thanks for the tip.

  • 2016-07-04 Victor Bocharsky

    Hey, Dan!

    If you don't have access to the console command - change your hosting provider ;)

    If seriously, you don't have many options here. You should run migration commands manually. You probably should have access to the PhpMyAdmin or credentials to connect to the database with MySQL Workbench. But in this case it's difficult to control it due to the human factor, you may miss something, which will cause an error. So the better option is to change your hosting provider.


  • 2016-07-03 Dan Costinel

    Hi Ryan,
    Little question: did you ever had a situation when you wanted to deploy a Symfony app into a server which doesn't provide a way to run console commands? What was your approach in that case? Because you say that whenever we need to deploy we need to run doctrine:migrations:migrate too... And I need to deploy a Symfony app without being able to run console commands

  • 2016-03-21 weaverryan

    Hi Hikaru!

    As far as I know, that's not possible: but it's by design. Since there is only *one* database, it's better to install a bundle then just run 'doctrine:migrations:diff' to generate whatever migrations you need from that bundle. I think the authors of DoctrineMigrationsBundle were just worried about installing a bundle, running doctrine:migrations:migrate and suddenly something has altered your production database - maybe without you realizing :).


  • 2016-03-18 Hikaru Shindo

    Is it possible to save migrations to the bundles they belong to in case you may have more then one bundle with entities and do not want to recreate the migrations on each project?