laravel-doctrine / migrations

Integration with Doctrine2's migrations package for Laravel

Laravel Doctrine Migrations

Doctrine Migrations for Laravel

migrations's Issues

Unexpected error in console commands in Lumen 5.5

Hello,

After I upgraded my Lumen from 5.4.36 to 5.5 the doctrine migration commands aren't working properly anymore, I've got an exception:

ReflectionException: Method LaravelDoctrine\Migrations\Console\GenerateCommand::handle() does not exist in ...

If I run doctrine:migration:diff then I've got a similar exception:

ReflectionException: Method LaravelDoctrine\Migrations\Console\DiffCommand::handle() does not exist in...

so in my opinion the migration commands are not working at all in Lumen 5.5.

migration on different env or connection

How can i do that?

This always returns Doctrine Connection named "pgsql" does not exist.

php artisan --connection=pgsql doctrine:migration:migrate

This always loads the environment defined in .env file

php artisan --env=testing doctrine:migration:migrate

How to register all migrations from package in the ServiceProvider laravel?

I have https://github.com/nWidart/laravel-modules this package, and i want to registered all migrations with ServiceProvider. How to make it???

Testing UseDatabaseMigrations UUID error

So not sure if this is the right place.
I think I found an error when trying to use the DatabaseMigrations trait on my Test classes. I have tried multiple avenues for the past few days, but keep getting the same error:

Doctrine\DBAL\DBALException: Unknown column type "uuid" requested.

I'm not sure if this trait uses your existing migrations? But I do have statements like
$table->uuid('id');
in my migrations that those tests might use.

Schema builder commands from diff tool

Currently the diff tool only generates a raw SQL migration. It would be useful to have it generate schema builder commands instead, at least as an option. That would be nicer to review and edit, and should also be more portable across different SQL backends (no need to regenerate the migration for each backend).

Add support for custom stubs for generate migrations

Command doctrine:migrations:generate uses 'stubs' files as templates for generate migration classes. It would be nice to have support for create custom stubs.

We need to add the same custom postUp() and postDown() methods to every generated migration. Now we have to add these methods manually and custom stub file is exactly the solution we need for adding these two methods to migration classes automatically.

How to implement:

Add new configuration option like stubs_path which can be pointed to directory with custom stubs files (blank.stub, create.stub, update.stub). In case the custom stub file doesn't exists the default one will be used.

[Bug] Add all versions do not work

# Package version, Laravel version
Laravel Framework 5.5.33
laravel-doctrine/migrations": 1.1.7
laravel-doctrine/orm": 1.4.3

Expected behavior

php artisan doctrine:migrations:version --all --add
should add all versions

Actual behavior

php artisan doctrine:migrations:version --all --add

Not enough arguments (missing: "version").

I think that a possible solution is to mark as optional version argument in the VersionCommand

The "force" option does not exist when running doctrine:migrations:rollback

$ php artisan doctrine:migrations:rollback

                                                                  
  [Symfony\Component\Console\Exception\InvalidArgumentException]  
  The "force" option does not exist.                              
                                                                  

$ php artisan doctrine:migrations:rollback --force

                                                          
  [Symfony\Component\Console\Exception\RuntimeException]  
  The "--force" option does not exist.                    
                                                          

Either this command should not use ConfirmableTrait or it should add a --force option.

Enhancement: per entity manager migration configs

Ran into this one yesterday: currently the migrations do not allow truly independent migrations for multiple entity managers. You can specify the connection etc. however the generated migrations do not maintain this information or provide a mechanism to only apply specific migrations and very quickly things descend into a mess.

Doing some research and the main Doctrine Migrations allows for a separate configuration to be provided, allowing completely different settings to be used for the migration config e.g: directory, namespace, table name etc.

The exact same thing can be done in this extension with very little extra effort and in a slightly more friendly way. I have implemented this in a branch in a fork of the repo and can make a PR if you want.
Commit: https://github.com/dave-redfern/migrations/commit/6dcc804e6ce24c856cc3c0b6b1eb6d6bb14a93f0

There is a BC break: I changed the config file format very slightly so now, the previous settings are in a connection sub-key. e.g.: migrations.default.name, migrations.default.directory.

The major benefit of all this, is you can have completely separate, isolated migrations including custom folders and namespaces allowing each entity manager to be managed individually. This mostly applies if you want to create an extension and provide entities / repos but it is intended to be run from its own DB but you want to allow the user to still custom and run their own migrations without mucking up their main app.

It's a limited use case I know, but it could maybe be used for different migrations in different environments as well through some creative naming.

Thoughts? Comments?

Migration diffs keep creating same migration

Hey there!

Weird thing going on when I run doctrine:migrations:diff without making any changes - it makes the same migration over and over.

This is the migration that it keeps making:

<?php

namespace Database\Migrations;

use Doctrine\DBAL\Migrations\AbstractMigration;
use Doctrine\DBAL\Schema\Schema as Schema;

class Version20160315014046 extends AbstractMigration
{
    /**
     * @param Schema $schema
     */
    public function up(Schema $schema)
    {
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('ALTER TABLE players ALTER buildings TYPE JSON');
        $this->addSql('ALTER TABLE players ALTER buildings DROP DEFAULT');
        $this->addSql('ALTER TABLE players ALTER research TYPE JSON');
        $this->addSql('ALTER TABLE players ALTER research DROP DEFAULT');
    }

    /**
     * @param Schema $schema
     */
    public function down(Schema $schema)
    {
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('CREATE SCHEMA public');
        $this->addSql('ALTER TABLE players ALTER buildings TYPE JSON');
        $this->addSql('ALTER TABLE players ALTER buildings DROP DEFAULT');
        $this->addSql('ALTER TABLE players ALTER research TYPE JSON');
        $this->addSql('ALTER TABLE players ALTER research DROP DEFAULT');
    }
}

Here's the YAML file:

# IronSteel.Game.Player.Player.dcm.yml
IronSteel\Game\Player\Player:
  type: entity
  table: players
  repositoryClass: IronSteel\Game\Player\PlayerRepository

  id:
    playerId:
      type: uuid

  fields:
    username:
      type: string

    email:
      type: string
      length: 100
      unique: true

    iron:
      type: integer
      options:
        unsigned: true
        default: 0

    gas:
      type: integer
      options:
        unsigned: true
        default: 0

    vapor:
      type: integer
      options:
        unsigned: true
        default: 0

    buildings:
      type: json
      nullable: true

    research:
      type: json
      nullable: true

    createdAt:
      column: created_at
      type: datetime

    updatedAt:
      column: updated_at
      type: datetime
      nullable: true

add support for laravel 5.5

after I upgrade to laravel 5.5. an laravel-doctrine/orm 1.3.x-dev

I got the following message:

[ReflectionException]
Method LaravelDoctrine\Migrations\Console\MigrateCommand::handle() does not exist

https://laravel.com/docs/5.5/upgrade says:

The fire Method
Any fire methods present on your Artisan commands should be renamed to handle.

Documentation is lacking information about migrations table

I looked into the documentation for 1.1 and I did not find any information about how to the migrations table should be set up.

The default migrations table from Laravel itself does not contain a version column (as far as I could tell).

Did I miss something?

Add support for Laravel 8

Hi! Please support for Laravel ver. 8.x 👍

Conflict on migration diff using Swagger annotations

I'm using zircote/swagger-php to create documentation of my project.

They use doctrine/annotations to generate the documentation.

I'm trying to find a way to use laravel-doctrine and zircote/swagger-php with annotations, and not yml, xml or other stuff.

Am i missing something really silly?

The error:
[Doctrine\Common\Annotations\AnnotationException]
[Semantical Error] The annotation "@SWG\Swagger" in class App\Http\Controllers\Controller was never imported. Did you maybe forget to add a "use" statement for this annotation?

"laravel/lumen-framework": "5.5."
"laravel-doctrine/orm": "1.3.",
"laravel-doctrine/migrations": "^1.1",
"laravel-doctrine/extensions": "1.0.12",
"zircote/swagger-php": "^2.0"

[BUG] Migrations diff doesn't work

I get this error on running migrations diff command

 Declaration of Database\Migrations\Version20200409152424::up(Doctrine\DBAL\Schema\Schema $schema) must be 
 compatible with Doctrine\Migrations\AbstractMigration::up(Doctrine\DBAL\Schema\Schema $schema): void

[Bug] VersionCommand --no-interaction should add migrations without asking confirmation

Package version, Laravel version

Laravel Framework 5.5.33
laravel-doctrine/migrations": 1.1.9
laravel-doctrine/orm": 1.4.3

Expected behavior

php artisan doctrine:migrations:version --all --add --no-interaction
should add all versions without asking for confirmation

Actual behavior

php artisan doctrine:migrations:version --all --add --no-interaction
Migration cancelled!

I'm going to submit a PR with a viable solution

[Bug] Refresh command command not working with filtered tables

Hi,

I'm trying to use the refresh command to rollback and migrate my database. I have a migration for a password_resets table.
When I run the refresh command, internally it calls the reset command and it doesn't drop the password_resets table because I have it in my migrations.schema.filter regex listed.
Then the refresh command calls the migrate command and it tries to create the password_resets table because this command doesn't account for the filter.

Removing it from the filter regex also isn't any good because then the diff command generates a migration to drop the table every time.

I think I'm doing something wrong like I should provide an extra option when running the command, but there doesn't seem to be any option.

Thanks in advance

[Bug?] --query-time option for MigrateCommand ignores blank value

Description

When running doctrine:migrations:migrate the --query-time option won't be counted unless you pass something to it. The command does not care what you put after, it will work with doctrine:migrations:migrate --query-time='hello'.

Code where the option is checked.

migrations/src/Console/MigrateCommand.php

Lines 72 to 76 in f1292c3

	$migrator->migrate(
	$migration,
	$this->option('dry-run') ? true : false,
	$this->option('query-time') ? true : false
	);

Current signature:

migrations/src/Console/MigrateCommand.php

Lines 18 to 28 in f1292c3

	/**
	* The name and signature of the console command.
	* @var string
	*/
	protected $signature = 'doctrine:migrations:migrate
	{version=latest : The version number (YYYYMMDDHHMMSS) or alias (first, prev, next, latest) to migrate to.}
	{--connection= : For a specific connection }
	{--write-sql= : The path to output the migration SQL file instead of executing it. }
	{--dry-run : Execute the migration as a dry run. }
	{--query-time= : Time all the queries individually. }
	{--force : Force the operation to run when in production. }';

Expected Behavior

The --query-time option should act like a standard boolean option. If I call the command with php artisan doctrine:migrations:migrate --query-time, it should report query times.

Actual Behavior

--query-time is ignored if there is no value passed to it. But any value passed to is treated as true.

Possible Fix

There are two options I've come up with:

1) Change the option signature.

Change {--query-time= : Time all the queries individually. } to {--query-time : Time all the queries individually. }. This will break current behavior, but treats the option like a switch both internally and externally.

2) Add default and change how the option is checked.

Change {--query-time= : Time all the queries individually. } to {--query-time=false : Time all the queries individually. }.

Change the logic to check for 'false' since --query-time will pass null as the value, while not using the option will return the string 'false':

$shouldTimeQuery = $this->option('query-time') !== 'false';

$migrator->migrate(
      $migration,
      $this->option('dry-run') ? true : false,
      $shouldTimeQuery
);

I personally prefer the first option. While it does change current behavior, it's more clear on how to use the option. The second option feels really dirty, but it works and preserves current behavior.

Steps to Reproduce

1. Create a migration.
2. Run php artisan doctrine:migrations:migrate --dry-run --query-time
3. The migrations will not be timed.
4. Run php artisan doctrine:migrations:migrate --dry-run --query-time='random string'
5. The migrations will be timed.

Update version constraints for laravel-doctrine/orm

Currently working around this by aliasing the new release in my composer.json file:

        "laravel-doctrine/orm": "1.3.0 as 1.2.10",

Migration stuck on Postgresql database

Hi there,

got the following error on migrating two entities two my postrgesql database. These tables are also related with a OneToMany relationship... so what.

Without the relationship the migration runs fine, but after adding the relationship I run in this error:

php artisan doctrine:migrations:refresh

  [Doctrine\DBAL\Exception\DriverException]
  An exception occurred while executing 'SET FOREIGN_KEY_CHECKS = 0;':
  SQLSTATE[42704]: Undefined object: 7 ERROR:  unrecognized configuration parameter "foreign_key_checks"

  [Doctrine\DBAL\Driver\PDOException]
  SQLSTATE[42704]: Undefined object: 7 ERROR:  unrecognized configuration parameter "foreign_key_checks"

  [PDOException]
  SQLSTATE[42704]: Undefined object: 7 ERROR:  unrecognized configuration parameter "foreign_key_checks"

I know that FOREIGN_KEY_CHECKS not compatible with Postgres, but my doctrine and database configs are also set to postgres.

Any ideas on this?

Thanks and regards,
Christian

refresh and reset command do not work for me while using postgres

Package version, Laravel version

laravel/framework v5.4.28 The Laravel Framework.
laravel-doctrine/orm 1.3.6 A Doctrine ORM bridge for Laravel 5
laravel-doctrine/migrations 1.1.5 Doctrine Migrations for Laravel

Expected behaviour

php artisan doctrine:migrations:reset
should reset the database... but instead it drops the migrations table first... ?

Actual behaviour

php artisan doctrine:migrations:reset


  [Doctrine\DBAL\Exception\TableNotFoundException]
  An exception occurred while executing 'ALTER TABLE migrations ENABLE TRIGGER ALL':
  SQLSTATE[42P01]: Undefined table: 7 ERROR:  relation "migrations" does not exist



  [Doctrine\DBAL\Driver\PDOException]
  SQLSTATE[42P01]: Undefined table: 7 ERROR:  relation "migrations" does not exist



  [PDOException]
  SQLSTATE[42P01]: Undefined table: 7 ERROR:  relation "migrations" does not exist

Steps to reproduce the behaviour

setup a new app using postgres as the datasource...
create a few entities
use php artisan doctrine:migrations:diff to create a migratino
migrate the table
php artisan doctrine:migrations:migrate
then try and reset:
It will fail because it seems like it drops the migrations table ?
If I look at my database afterward... all my database tables still exist except the migrations table.

Also... reset doesn't something similar.

If I migrate and rollback manually everything works fine... it's only the reset or refresh commands that don't work for me.

NOTE: Did some further testing tonight, and Everything works fine with mysql... but reset, refresh are both broken for Postgres...

Reset command does not work on anything but MySQL

As noted in this old issue from 2013. SET FOREIGN_KEY_CHECKS = 0 is MySQL specific. But ResetCommand::fire wraps the dropTable calls with it, which will fail on e.g. sqlite.

How to ignore custom tables

I have some tables for which there is no doctrine mapping file. When I run:

php artisan doctrine:migrations:diff

The SQL migration contains a DROP for those tables.

I do not know how to tell doctrine to ignore some tables:

http://doctrine-orm.readthedocs.io/projects/doctrine-migrations/en/latest/reference/generating_migrations.html#ignoring-custom-tables

Is there a way to add a "ignore table list" in the config file?

doctrine:migrations:refresh command does not work on reserved MySQL keywords

When I try to run "doctrine:migrations:refresh", the following error occurs:

Doctrine\DBAL\Exception\SyntaxErrorException  : An exception occurred while executing 'DROP TABLE order':

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'order' at line 1

The problem occurs when trying to drop a table which has some of the reserved MySQL keywords like ORDER.

When you look at src/Console/ResetCommand.php, line 91:

$schema->dropTable($table);

The problem is solved if you put quotes ` between $table variable:

https://i.imgur.com/r9E8yz0.png

Is there any other solution to the problem or a possible fix?

--dry-run flag ignored when running doctrine:migrations:migrate

For some reason, the --dry-run flag seems to be ignored when I try to run it with the migrate command. I tried to see where the problem lies but couldn't really find anything. Since this library mostly passes CLI arguments to internal Doctrine classes, not much should be able to go wrong here from this lib's end.

Can anyone perhaps test this out as well so I know this isn't just on my side?

[Feature] Display the migration output from the base Doctrine migrator.

Detailed Description

Currently only the migration notes are displayed. But any other output from the base doctrine migrator won't be written to console.

Context

It would be nice to see the extra output from doctrine. I made a quick, dirty solution to show the difference.

Current behavior:

With doctrine output:

Possible Implementation

Doctrine's \Doctrine\DBAL\Migrations\Configuration\Configuration class has an outputWriter property. The property must be an instance of \Doctrine\DBAL\Migrations\OutputWriter. Here is my dirty workaround.

I set the output writer after retrieving the configuration from the provider.

migrations/src/Console/MigrateCommand.php

Lines 49 to 53 in f1292c3

	$configuration = $provider->getForConnection(
	$this->option('connection') ?: null
	);

        $configuration->setOutputWriter(new OutputWriter(function($message){
                // Get  the current command's output handler.
        	$output = $this->getOutput();
               // Verify the handler exists and that we want extra output.
        	if($output && $output->isVerbose()){
                        // Write the output to a new line.
        		$output->write($message,true);
	        }
        }));

I don't know how to get an Artisan command's output handler from the ConfigurationFactory. The only way I know how is to get it from the command itself.

Edit

The command could also pass it's output handler to the ConfigurationProvider::getForConnection() method.

Support for UUID field type

I'm trying to implement a schema migration involving a custom uuid field type but I'm not exactly sure if this is something that can be done using the LaravelDoctrine\Migrations classes. I added my custom type to the doctrine configuration and mapping as so:

'mapping_types' => [
    'uuid'        => 'uuid',
    'uuid_binary' => 'binary',
],
'custom_types' => [
    'uuid'        => Ramsey\Uuid\Doctrine\UuidType::class,
    'uuid_binary' => Ramsey\Uuid\Doctrine\UuidBinaryType::class,
]

But it doesn't seem like the query/schema builder supports custom types at all:

$table->uuid('id');

  [Symfony\Component\Debug\Exception\FatalThrowableError]
  Fatal error: Call to undefined method LaravelDoctrine\Migrations\Schema\Table::uuid()

So I went back and just tried to create a BINARY(16) to store my UUID by doing this in the migration:

namespace Database\Migrations;

use Doctrine\DBAL\Migrations\AbstractMigration;
use Doctrine\DBAL\Schema\Schema as Schema;
use LaravelDoctrine\Migrations\Schema\Builder;
use LaravelDoctrine\Migrations\Schema\Table;

class Version20160126164625 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        $builder = new Builder($schema);
        $builder->create('payment_types', function(Table $table) {
            $table->binary('id', 16);
            $table->string('name');
        });
    }
}

But the builder doesn't support length on binary fields and doesn't support the uuid field type from Laravel either. Do you have any idea how we're supposed to proceed in this situation?

Adding a column after another existing column

Laravel 5.3 exposes a method to add a column to a table at a precise position (after a given existing column). I think it's missing from this library or did I miss it somewhere?

generating migrations based on config

Hello, I tried changing the default migrations config to:

'directory' => database_path('migrations/doctrine'),
'namespace' => 'Database\\Migrations\\Doctrine',

but it seams it has no effect at all on generating migrations. They are still created in the default namespace.

Can you check please?

Thanks!

Support option: organize_migrations

Subject.

For add the ability to auto create migrations in a folder by month and year.

[Bug] DatabaseMigrations trait rollsback only the latest migration

I believe, The behavior of this trait LaravelDoctrine\Migrations\Testing\DatabaseMigrations is not correct. At the beginning of the test runDatabaseMigrations runs all of the migrations and makes the test database ready. But after the test is finished line 21 is executed which is doctrine:migrations:rollback and it only rollsback the latest migration and all of the other migrations are still in the test database.

I cannot understand why does the last migration have to be rolled back and the rest of them stay?

Undefined method Kernel::setArtisan() in DatabaseMigrations trait

I'm using the DatabaseMigrations trait for my tests with Lumen 5.6 and I'm getting this error:
Call to undefined method App\Console\Kernel::setArtisan()

Is it possible that the line
$this->app[Kernel::class]->setArtisan(null);
just worked for a previous Laravel version, or did I miss to bind a special Kernel?

Migration in postgres always adds $this->addSql('CREATE SCHEMA public'); to the down() in migration

laravel-doctrine/orm 1.3.6 A Doctrine ORM bridge for Laravel 5
laravel-doctrine/scout 0.1.1 A Doctrine bridge for Laravel Scout
laravel/framework v5.4.28 The Laravel Framework.

I run the diff and then the migration and it builds my database etc...
Then I run diff again and it always creates a new migration with this line:

public function down(Schema $schema)
{
    $this->addSql('CREATE SCHEMA public'); 
}

I searched for the issue online and found a similar issue for doctrine on the dbal github: doctrine/dbal#1110

Their is a suggested fix for those using doctrine with symfony...

I was able to implement the fix for myself, but figured I would create this issue in case someone wants to fix it and/or if another searches for a fix. Here is what I did.

I created this file:

<?php

namespace EngineBundle\Doctrine;

use Doctrine\Common\EventSubscriber;
use Doctrine\ORM\Tools\Event\GenerateSchemaEventArgs;

class MigrationEventSubscriber implements EventSubscriber
{
    public function getSubscribedEvents()
    {
        return array(
            'postGenerateSchema',
        );
    }

    public function postGenerateSchema(GenerateSchemaEventArgs $Args)
    {
        $Schema = $Args->getSchema();

        if (! $Schema->hasNamespace('public')) {
            $Schema->createNamespace('public');
        }
    }
}

Then I put the event subscriber into my doctrine.php config file

'events' => [
    'listeners' => [],
    'subscribers' => [\App\Isaac\Doctrine\Subscribers\MigrationEventSubscriber::class]
],
'filters' => [],

I'm actually not really sure why that fixes it, still learning doctrine and how this config file works... If someone has a better fix let me know.

thanks.

Unable to run migrations

Recently installed laravel-doctrine in my laravel 5.5 project and started making migrations using doctrine. Now when I try to run: php artisan doctrine:migrations:migrate

It returns the following error:

In Version20180122094236.php line 20:

Call to undefined method Doctrine\DBAL\Schema\Column::index()

This is the migration file it's complaining about:

<?php

namespace Database\Migrations;

use Doctrine\DBAL\Migrations\AbstractMigration;
use Doctrine\DBAL\Schema\Schema as Schema;
use LaravelDoctrine\Migrations\Schema\Table;
use LaravelDoctrine\Migrations\Schema\Builder;

class Version20180122094136 extends AbstractMigration
{
    protected $tableName = "users";

    /**
     * @param Schema $schema
     */
    public function up(Schema $schema)
    {
        (new Builder($schema))->create($this->tableName, function (Table $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('email');
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }

    /**
     * @param Schema $schema
     */
    public function down(Schema $schema)
    {
        (new Builder($schema))->drop($this->tableName);
    }
}

my composer.json looks as follow:

 "require": {
        "php": ">=7.0.0",
        "doctrine/dbal": "^2.6",
        "fideloper/proxy": "~3.3",
        "laravel-doctrine/migrations": "^1.1",
        "laravel-doctrine/orm": "1.4.*",
        "laravel/framework": "5.5.*",
        "laravel/tinker": "~1.0"
    }

Any tips of what may cause this error?

Call to undefined function LaravelDoctrine\Migrations\str_contains()

Since Laravel 6.0, str_ and array_ helpers have been moved to a new package. Instead of requiring this new laravel/helpers package, it's better if we use what's already under #Illuminate\Support.

doctrine:schema:update tries to drop the migration table

When running php artisan doctrine:schema:update --sql I get the following output:

$ php artisan doctrine:schema:update --sql
Checking if database needs updating....
Outputting update query:
DROP TABLE doctrine_migration_version;

This shouldn't happen as the doctrine_migration_version table is the table which stores the migrations (as set in our configuration).

Using laravel-doctrine/migrations 1.0.6 & laravel-doctrine/orm 1.1.2

Default schema filter doesn't filters failed_jobs table

For some reason, the default filter doesn't seems to work for me. Whenever I run php artisan doctrine:migrations:diff it creates a migration that tries to drop the failed_jobs table. Any idea what might be wrong?

'schema' => [
    'filter' => '/^(?!password_resets|failed_jobs).*$/',
],

--allow-no-migration

I cant see any docs nor can i run the follow command - i use this in symfony projects and it would be great if you could add it!

Migration script tries to create migrations table always

Hi:

I have renamed migrations table name to avoid conflicts with Laravel/Eloquent migrations table:

    /*
    |--------------------------------------------------------------------------
    | Migration Repository Table
    |--------------------------------------------------------------------------
    |
    | This table keeps track of all the migrations that have already run for
    | your application. Using this information, we can determine which of
    | the migrations on disk haven't actually been run in the database.
    |
    */
    'table'     => 'migrations_doctrine',

But now, every time I try to execute migration script: php artisan doctrine:migrations:migrate
I get this error:

 [Doctrine\DBAL\Exception\TableExistsException]
  An exception occurred while executing 'CREATE TABLE migrations_doctrine (version VARCHAR(255) NOT NULL, PRIMARY KEY(version)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB':
  SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'migrations_doctrine' already exists

I have tried to remove completely the database and then create the schema and run migrations.
The first time I run the migration script it works, but the second time it fails with that error. The migrations_doctrine table contains all the versions of the migrations executed the first time.

Named migrations

I would like to include the purpose of each migration in the file name. So instead of Version20150915130401.php, it might be something like Version20150915130401.cool_new_feature.php. Then it would be easily visible what each migration does.

I saw in the code that there's a NamingStrategy interface and an undocumented naming_strategy config setting, which I can use to implement a custom naming strategy. But it would be nice to have console command support for working with named migrations.

MigrateCommand in non-interactive mode exits with 1 error code when there are unavailable migrations

Hello,

considering there is one row in database migration table and there are no migration files in code base,
running

php artisan doctrine:migrations:migrate --no-interaction --force

outputs

WARNING! You have previously executed migrations in the database that are not registered migrations.
[...]
Migration cancelled!

In non-interaction mode it should print a warning, but proceed with migration execution (as implemented in doctrine/migrations MigrateCommand command).

Correct me if i'm wrong, but currently there is no way to overcome this warning.

I can submit a PR for this, just let me know.

symfony/yaml version

Hi

Just doing a default install, along the lines below and when adding migrations get a package conflict on symfony/yaml[v2.3.0, v3.0.0]. I suspect that v3 has been released recently

To reproduce
composer create-project laravel/laravel --prefer-dist app_name
cd app_name
composer require firebase/php-jwt
composer require guzzlehttp/guzzle
composer require laravel-doctrine/orm
composer require laravel-doctrine/extensions
composer require laravel-doctrine/acl
composer require laravel-doctrine/migrations

All migrations are created with altering `sessions` table

Bug Report

Q	A
BC Break	no
laravel-doctrine/migrations version	1.1.10
Laravel Framework version	5.6.25
php version	7.2.7-1
MySQL version	5.7.22

Summary

When running artisan doctrine:migrations:diff it's always creates migration that contains changes to sessions table.

Current behavior

Running artisan doctrine:migrations:diff creates migration that contains SQL code below

The up addSql will look like

ALTER TABLE sessions CHANGE id id VARCHAR(255) NOT NULL

The down addSql will look like

ALTER TABLE sessions CHANGE id id VARCHAR(255) NOT NULL COLLATE utf8mb4_unicode_ci

How to reproduce

• create new laravel app
• add SESSION_DRIVER=database to .env
• run artisan session:table
• run artisan migrations:migrate
• make basic configurations to laravel-doctrine (use xml mappings)
• run artisan doctrine:mapping:import --namespace=Your\\Namespace\\ xml Your/Mappings/Folder
• run artisan doctrine:migrations:diff. It will create migration with session table changes.

My current xml for sessions table is

<?xml version="1.0" encoding="utf-8"?>
<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="Foo\Bar\Session"
          table="sessions"
          repository-class="Foo\Bar\SessionRepository"
  >
    <unique-constraints>
      <unique-constraint name="sessions_id_unique" columns="id"/>
    </unique-constraints>
    <id name="id" type="string" column="id" length="255">
      <generator strategy="IDENTITY"/>
    </id>
    <field name="ipAddress" type="string" column="ip_address" length="45" nullable="true">
      <options>
        <option name="fixed"/>
      </options>
    </field>
    <field name="userAgent" type="text" column="user_agent" length="65535" nullable="true">
      <options>
        <option name="fixed"/>
      </options>
    </field>
    <field name="payload" type="text" column="payload" length="65535" nullable="false">
      <options>
        <option name="fixed"/>
      </options>
    </field>
    <field name="lastActivity" type="integer" column="last_activity" nullable="false">
      <options>
        <option name="unsigned"/>
      </options>
    </field>
    <many-to-one field="user" target-entity="App\Doctrine\Entity\User"  inversed-by="sessions" fetch="LAZY">
      <join-columns>
        <join-column name="user_id" referenced-column-name="id"/>
      </join-columns>
    </many-to-one>
  </entity>
</doctrine-mapping>

My doctrine.php (showing only changes because it's almost similar) is

'managers'                   => [
        'default' => [
            'dev'           => env('APP_DEBUG', false),
            'meta'          => env('DOCTRINE_METADATA', 'xml'),
            'connection'    => env('DB_CONNECTION', 'mysql'),
            'namespaces'    => [],
            'paths'         => [
                base_path('Your/Mappings/Folder')
            ],
        ]
    ],

Expected behavior

Running artisan doctrine:migrations:diff gives error with message No changes detected in your mapping information. Like on screenshot

Changed migrations table name and now it tries to create it every time

Hi, I'm using the lumen migrations for the failed_jobs table... So, I changed the name for the table to "migrations_doctrine" in the config file.. But now each time I try to add a new migration I get errors about:

An exception occurred while executing 'CREATE TABLE migrations_doctrine (version VARCHAR(255) NOT NULL, PRIMARY KEY(version)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB': 
SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'migrations_doctrine' already exists      

Should I blacklist migrations_doctrine too?

Add support for Doctrine Migrations 2.0

I have been working on Doctrine Migrations 2.0 in https://github.com/doctrine/migrations master.

Opening an issue here to discuss and track progress for upgrading this library to 2.0.

Migrations diff and postgres schema problem with recreating existing tables

Package	Version
doctrine/annotations	v1.6.0
doctrine/dbal	v2.9.2
doctrine/migrations	v1.8.1
doctrine/orm	v2.6.3
laravel-doctrine/migrations	1.2.0
laravel-doctrine/orm	1.4.9
laravel/framework	v5.7.27
PostgreSQL	9.6.11
PHP	7.2.15

Summary

Running doctrine:migrations:diff multiple times without any changes and with existing table in database always generate the same code trying to create table with schema and delete the very same table without schema.

How to reproduce

On any project create entity:

/**
 * @ORM\Entity(repositoryClass = "App\Domain\Repositories\UserRepository")
 * @ORM\Table(name = "users", schema = "public")
 */
class User
{

    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy = "IDENTITY")
     * @ORM\Column(type = "integer")
     */
    protected $id;

    /**
     * @ORM\Column(type="string", length = 64, nullable = false, unique = true)
     * @var string
     */
    protected $username;

}

Run doctrine:migrations:diff

Generated migration is ok now:

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

$this->addSql('CREATE TABLE public.users (id SERIAL NOT NULL, username VARCHAR(64) NOT NULL, PRIMARY KEY(id))');
$this->addSql('CREATE UNIQUE INDEX UNIQ_2552C48DF85E0677 ON public.users (username)');

Run doctrine:migrations:migrate and table is created succesfully in database.

Run doctrine:migrations:diff and new migration is generated:

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

$this->addSql('CREATE TABLE public.users (id SERIAL NOT NULL, username VARCHAR(64) NOT NULL, PRIMARY KEY(id))');
$this->addSql('CREATE UNIQUE INDEX UNIQ_2552C48DF85E0677 ON public.users (username)');
$this->addSql('DROP TABLE users');

Of course next running doctrine:migrations:migrate ends with error

relation "users" already exists

Comment

I don't know if this behavior is related to laravel-doctrine or doctrine itself so I also created bug report in doctrine issue tracker

setGeneratorStrategy throws a type error

I have a Laravel 5.4 application with Laravel-Doctrine/migrations 1.1 configured. When I log into the workspace to run artisan commands, the Doctrine migrations fail with this error:

$ php artisan doctrine:migrations:migrate

 [Symfony\Component\Debug\Exception\FatalThrowableError]
  Type error: Return value of ProxyManager\Configuration::setGeneratorStrategy() must be an instance of ProxyManager\void, none returned

Here is the verbose output:

Exception trace:
 () at /var/www/vendor/ocramius/proxy-manager/src/ProxyManager/Configuration.php:124
 ProxyManager\Configuration->setGeneratorStrategy() at /var/www/vendor/doctrine/migrations/lib/Doctrine/DBAL/Migrations/Provider/LazySchemaDiffProvider.php:45
 Doctrine\DBAL\Migrations\Provider\LazySchemaDiffProvider::fromDefaultProxyFacyoryConfiguration() at /var/www/vendor/doctrine/migrations/lib/Doctrine/DBAL/Migrations/Version.php:120
 Doctrine\DBAL\Migrations\Version->__construct() at /var/www/vendor/doctrine/migrations/lib/Doctrine/DBAL/Migrations/Configuration/Configuration.php:416
 Doctrine\DBAL\Migrations\Configuration\Configuration->registerMigration() at /var/www/vendor/doctrine/migrations/lib/Doctrine/DBAL/Migrations/Configuration/Configuration.php:436
 Doctrine\DBAL\Migrations\Configuration\Configuration->registerMigrations() at /var/www/vendor/doctrine/migrations/lib/Doctrine/DBAL/Migrations/Configuration/Configuration.php:393
 Doctrine\DBAL\Migrations\Configuration\Configuration->registerMigrationsFromDirectory() at /var/www/vendor/laravel-doctrine/migrations/src/Configuration/ConfigurationFactory.php:64
 LaravelDoctrine\Migrations\Configuration\ConfigurationFactory->make() at /var/www/vendor/laravel-doctrine/migrations/src/Configuration/ConfigurationProvider.php:38
 LaravelDoctrine\Migrations\Configuration\ConfigurationProvider->getForConnection() at /var/www/vendor/laravel-doctrine/migrations/src/Console/MigrateCommand.php:51
 LaravelDoctrine\Migrations\Console\MigrateCommand->fire() at n/a:n/a
 call_user_func_array() at /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:28
 Illuminate\Container\BoundMethod::Illuminate\Container\{closure}() at /var/www/vendor/laravel/framework/src/Illuminate/Support/helpers.php:912
 value() at /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:86
 Illuminate\Container\BoundMethod::callBoundMethod() at /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:30
 Illuminate\Container\BoundMethod::call() at /var/www/vendor/laravel/framework/src/Illuminate/Container/Container.php:524
 Illuminate\Container\Container->call() at /var/www/vendor/laravel/framework/src/Illuminate/Console/Command.php:182
 Illuminate\Console\Command->execute() at /var/www/vendor/symfony/console/Command/Command.php:262
 Symfony\Component\Console\Command\Command->run() at /var/www/vendor/laravel/framework/src/Illuminate/Console/Command.php:167
 Illuminate\Console\Command->run() at /var/www/vendor/symfony/console/Application.php:826
 Symfony\Component\Console\Application->doRunCommand() at /var/www/vendor/symfony/console/Application.php:189
 Symfony\Component\Console\Application->doRun() at /var/www/vendor/symfony/console/Application.php:120
 Symfony\Component\Console\Application->run() at /var/www/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php:123
 Illuminate\Foundation\Console\Kernel->handle() at /var/www/artisan:35

Here is the migration I'm trying to run:

class Version20170209064725 extends AbstractMigration
{
    /**
     * @param Schema $schema
     */
    public function up(Schema $schema)
    {
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'mysql', 'Migration can only be executed safely on \'mysql\'.');
        $this->addSql('CREATE TABLE users (id INT AUTO_INCREMENT NOT NULL, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
    }
    /**
     * @param Schema $schema
     */
    public function down(Schema $schema)
    {
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'mysql', 'Migration can only be executed safely on \'mysql\'.');
        $this->addSql('DROP TABLE users');
    }
}

This was generated with the php artisan doctrine:migrations:diff and sucked up the annotations on my entity, which are these:

/**
     * @var int
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @ORM\Column(type="integer", nullable=false)
     */
    protected $id;

I think this is a bug with the ProxyGenerator but it's coming through the Laravel-Doctrine package and wanted to share it with you first.

Dependency problem with doctrine/migrations 1.4.0 in Laravel 7.4.0

I tried to install laravel-doctrine/migrations in Laravel 7.4.0 and I'm getting dependency problems with it check composer output.

Problem 1 - Conclusion: don't install laravel-doctrine/migrations 1.4.0 - Conclusion: remove symfony/console v5.0.7 - Installation request for laravel-doctrine/migrations ^1.4 -> satisfiable by laravel-doctrine/migrations[1.4.0, 1.4.x-dev]. - Conclusion: don't install symfony/console v5.0.7 - laravel-doctrine/migrations 1.4.x-dev requires doctrine/migrations ~1.8 -> satisfiable by doctrine/migrations[1.8.x-dev, v1.8.0, v1.8.1]. - doctrine/migrations 1.8.x-dev requires symfony/console ~3.3|^4.0 -> satisfiable by symfony/console[3.3.x-dev, 3.4.x-dev, 4.0.x-dev, 4.1.x-dev, 4.2.x-dev, 4.3.x-dev, 4.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.14, v3.3.15, v3.3.16, v3.3.17, v3.3.18, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v3.4.1, v3.4.10, v3.4.11, v3.4.12, v3.4.13, v3.4.14, v3.4.15, v3.4.16, v3.4.17, v3.4.18, v3.4.19, v3.4.2, v3.4.20, v3.4.21, v3.4.22, v3.4.23, v3.4.24, v3.4.25, v3.4.26, v3.4.27, v3.4.28, v3.4.29, v3.4.3, v3.4.30, v3.4.31, v3.4.32, v3.4.33, v3.4.34, v3.4.35, v3.4.36, v3.4.37, v3.4.38, v3.4.39, v3.4.4, v3.4.5, v3.4.6, v3.4.7, v3.4.8, v3.4.9, v4.0.0, v4.0.0-BETA1, v4.0.0-BETA2, v4.0.0-BETA3, v4.0.0-BETA4, v4.0.0-RC1, v4.0.0-RC2, v4.0.1, v4.0.10, v4.0.11, v4.0.12, v4.0.13, v4.0.14, v4.0.15, v4.0.2, v4.0.3, v4.0.4, v4.0.5, v4.0.6, v4.0.7, v4.0.8, v4.0.9, v4.1.0, v4.1.0-BETA1, v4.1.0-BETA2, v4.1.0-BETA3, v4.1.1, v4.1.10, v4.1.11, v4.1.12, v4.1.2, v4.1.3, v4.1.4, v4.1.5, v4.1.6, v4.1.7, v4.1.8, v4.1.9, v4.2.0, v4.2.0-BETA1, v4.2.0-BETA2, v4.2.0-RC1, v4.2.1, v4.2.10, v4.2.11, v4.2.12, v4.2.2, v4.2.3, v4.2.4, v4.2.5, v4.2.6, v4.2.7, v4.2.8, v4.2.9, v4.3.0, v4.3.0-BETA1, v4.3.0-BETA2, v4.3.0-RC1, v4.3.1, v4.3.10, v4.3.11, v4.3.2, v4.3.3, v4.3.4, v4.3.5, v4.3.6, v4.3.7, v4.3.8, v4.3.9, v4.4.0, v4.4.0-BETA1, v4.4.0-BETA2, v4.4.0-RC1, v4.4.1, v4.4.2, v4.4.3, v4.4.4, v4.4.5, v4.4.6, v4.4.7]. - doctrine/migrations v1.8.1 requires symfony/console ~3.3|^4.0 -> satisfiable by symfony/console[3.3.x-dev, 3.4.x-dev, 4.0.x-dev, 4.1.x-dev, 4.2.x-dev, 4.3.x-dev, 4.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.14, v3.3.15, v3.3.16, v3.3.17, v3.3.18, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v3.4.1, v3.4.10, v3.4.11, v3.4.12, v3.4.13, v3.4.14, v3.4.15, v3.4.16, v3.4.17, v3.4.18, v3.4.19, v3.4.2, v3.4.20, v3.4.21, v3.4.22, v3.4.23, v3.4.24, v3.4.25, v3.4.26, v3.4.27, v3.4.28, v3.4.29, v3.4.3, v3.4.30, v3.4.31, v3.4.32, v3.4.33, v3.4.34, v3.4.35, v3.4.36, v3.4.37, v3.4.38, v3.4.39, v3.4.4, v3.4.5, v3.4.6, v3.4.7, v3.4.8, v3.4.9, v4.0.0, v4.0.0-BETA1, v4.0.0-BETA2, v4.0.0-BETA3, v4.0.0-BETA4, v4.0.0-RC1, v4.0.0-RC2, v4.0.1, v4.0.10, v4.0.11, v4.0.12, v4.0.13, v4.0.14, v4.0.15, v4.0.2, v4.0.3, v4.0.4, v4.0.5, v4.0.6, v4.0.7, v4.0.8, v4.0.9, v4.1.0, v4.1.0-BETA1, v4.1.0-BETA2, v4.1.0-BETA3, v4.1.1, v4.1.10, v4.1.11, v4.1.12, v4.1.2, v4.1.3, v4.1.4, v4.1.5, v4.1.6, v4.1.7, v4.1.8, v4.1.9, v4.2.0, v4.2.0-BETA1, v4.2.0-BETA2, v4.2.0-RC1, v4.2.1, v4.2.10, v4.2.11, v4.2.12, v4.2.2, v4.2.3, v4.2.4, v4.2.5, v4.2.6, v4.2.7, v4.2.8, v4.2.9, v4.3.0, v4.3.0-BETA1, v4.3.0-BETA2, v4.3.0-RC1, v4.3.1, v4.3.10, v4.3.11, v4.3.2, v4.3.3, v4.3.4, v4.3.5, v4.3.6, v4.3.7, v4.3.8, v4.3.9, v4.4.0, v4.4.0-BETA1, v4.4.0-BETA2, v4.4.0-RC1, v4.4.1, v4.4.2, v4.4.3, v4.4.4, v4.4.5, v4.4.6, v4.4.7]. - doctrine/migrations v1.8.0 requires symfony/console ^3.4||^4.0 -> satisfiable by symfony/console[3.4.x-dev, 4.0.x-dev, 4.1.x-dev, 4.2.x-dev, 4.3.x-dev, 4.4.x-dev, v3.4.0, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v3.4.1, v3.4.10, v3.4.11, v3.4.12, v3.4.13, v3.4.14, v3.4.15, v3.4.16, v3.4.17, v3.4.18, v3.4.19, v3.4.2, v3.4.20, v3.4.21, v3.4.22, v3.4.23, v3.4.24, v3.4.25, v3.4.26, v3.4.27, v3.4.28, v3.4.29, v3.4.3, v3.4.30, v3.4.31, v3.4.32, v3.4.33, v3.4.34, v3.4.35, v3.4.36, v3.4.37, v3.4.38, v3.4.39, v3.4.4, v3.4.5, v3.4.6, v3.4.7, v3.4.8, v3.4.9, v4.0.0, v4.0.0-BETA1, v4.0.0-BETA2, v4.0.0-BETA3, v4.0.0-BETA4, v4.0.0-RC1, v4.0.0-RC2, v4.0.1, v4.0.10, v4.0.11, v4.0.12, v4.0.13, v4.0.14, v4.0.15, v4.0.2, v4.0.3, v4.0.4, v4.0.5, v4.0.6, v4.0.7, v4.0.8, v4.0.9, v4.1.0, v4.1.0-BETA1, v4.1.0-BETA2, v4.1.0-BETA3, v4.1.1, v4.1.10, v4.1.11, v4.1.12, v4.1.2, v4.1.3, v4.1.4, v4.1.5, v4.1.6, v4.1.7, v4.1.8, v4.1.9, v4.2.0, v4.2.0-BETA1, v4.2.0-BETA2, v4.2.0-RC1, v4.2.1, v4.2.10, v4.2.11, v4.2.12, v4.2.2, v4.2.3, v4.2.4, v4.2.5, v4.2.6, v4.2.7, v4.2.8, v4.2.9, v4.3.0, v4.3.0-BETA1, v4.3.0-BETA2, v4.3.0-RC1, v4.3.1, v4.3.10, v4.3.11, v4.3.2, v4.3.3, v4.3.4, v4.3.5, v4.3.6, v4.3.7, v4.3.8, v4.3.9, v4.4.0, v4.4.0-BETA1, v4.4.0-BETA2, v4.4.0-RC1, v4.4.1, v4.4.2, v4.4.3, v4.4.4, v4.4.5, v4.4.6, v4.4.7]. - Can only install one of: symfony/console[3.3.x-dev, v5.0.7]. - Can only install one of: symfony/console[3.4.x-dev, v5.0.7]. - Can only install one of: symfony/console[4.0.x-dev, v5.0.7]. - Can only install one of: symfony/console[4.1.x-dev, v5.0.7]. - Can only install one of: symfony/console[4.2.x-dev, v5.0.7]. - Can only install one of: symfony/console[4.3.x-dev, v5.0.7]. - Can only install one of: symfony/console[4.4.x-dev, v5.0.7]. - Can only install one of: symfony/console[v3.3.0, v5.0.7]. - Can only install one of: symfony/console[v3.3.0-BETA1, v5.0.7]. - Can only install one of: symfony/console[v3.3.0-RC1, v5.0.7]. - Can only install one of: symfony/console[v3.3.1, v5.0.7]. - Can only install one of: symfony/console[v3.3.10, v5.0.7]. - Can only install one of: symfony/console[v3.3.11, v5.0.7]. - Can only install one of: symfony/console[v3.3.12, v5.0.7]. - Can only install one of: symfony/console[v3.3.13, v5.0.7]. - Can only install one of: symfony/console[v3.3.14, v5.0.7]. - Can only install one of: symfony/console[v3.3.15, v5.0.7]. - Can only install one of: symfony/console[v3.3.16, v5.0.7]. - Can only install one of: symfony/console[v3.3.17, v5.0.7]. - Can only install one of: symfony/console[v3.3.18, v5.0.7]. - Can only install one of: symfony/console[v3.3.2, v5.0.7]. - Can only install one of: symfony/console[v3.3.3, v5.0.7]. - Can only install one of: symfony/console[v3.3.4, v5.0.7]. - Can only install one of: symfony/console[v3.3.5, v5.0.7]. - Can only install one of: symfony/console[v3.3.6, v5.0.7]. - Can only install one of: symfony/console[v3.3.7, v5.0.7]. - Can only install one of: symfony/console[v3.3.8, v5.0.7]. - Can only install one of: symfony/console[v3.3.9, v5.0.7]. - Can only install one of: symfony/console[v3.4.0, v5.0.7]. - Can only install one of: symfony/console[v3.4.0-BETA1, v5.0.7]. - Can only install one of: symfony/console[v3.4.0-BETA2, v5.0.7]. - Can only install one of: symfony/console[v3.4.0-BETA3, v5.0.7]. - Can only install one of: symfony/console[v3.4.0-BETA4, v5.0.7]. - Can only install one of: symfony/console[v3.4.0-RC1, v5.0.7]. - Can only install one of: symfony/console[v3.4.0-RC2, v5.0.7]. - Can only install one of: symfony/console[v3.4.1, v5.0.7]. - Can only install one of: symfony/console[v3.4.10, v5.0.7]. - Can only install one of: symfony/console[v3.4.11, v5.0.7]. - Can only install one of: symfony/console[v3.4.12, v5.0.7]. - Can only install one of: symfony/console[v3.4.13, v5.0.7]. - Can only install one of: symfony/console[v3.4.14, v5.0.7]. - Can only install one of: symfony/console[v3.4.15, v5.0.7]. - Can only install one of: symfony/console[v3.4.16, v5.0.7]. - Can only install one of: symfony/console[v3.4.17, v5.0.7]. - Can only install one of: symfony/console[v3.4.18, v5.0.7]. - Can only install one of: symfony/console[v3.4.19, v5.0.7]. - Can only install one of: symfony/console[v3.4.2, v5.0.7]. - Can only install one of: symfony/console[v3.4.20, v5.0.7]. - Can only install one of: symfony/console[v3.4.21, v5.0.7]. - Can only install one of: symfony/console[v3.4.22, v5.0.7]. - Can only install one of: symfony/console[v3.4.23, v5.0.7]. - Can only install one of: symfony/console[v3.4.24, v5.0.7]. - Can only install one of: symfony/console[v3.4.25, v5.0.7]. - Can only install one of: symfony/console[v3.4.26, v5.0.7]. - Can only install one of: symfony/console[v3.4.27, v5.0.7]. - Can only install one of: symfony/console[v3.4.28, v5.0.7]. - Can only install one of: symfony/console[v3.4.29, v5.0.7]. - Can only install one of: symfony/console[v3.4.3, v5.0.7]. - Can only install one of: symfony/console[v3.4.30, v5.0.7]. - Can only install one of: symfony/console[v3.4.31, v5.0.7]. - Can only install one of: symfony/console[v3.4.32, v5.0.7]. - Can only install one of: symfony/console[v3.4.33, v5.0.7]. - Can only install one of: symfony/console[v3.4.34, v5.0.7]. - Can only install one of: symfony/console[v3.4.35, v5.0.7]. - Can only install one of: symfony/console[v3.4.36, v5.0.7]. - Can only install one of: symfony/console[v3.4.37, v5.0.7]. - Can only install one of: symfony/console[v3.4.38, v5.0.7]. - Can only install one of: symfony/console[v3.4.39, v5.0.7]. - Can only install one of: symfony/console[v3.4.4, v5.0.7]. - Can only install one of: symfony/console[v3.4.5, v5.0.7]. - Can only install one of: symfony/console[v3.4.6, v5.0.7]. - Can only install one of: symfony/console[v3.4.7, v5.0.7]. - Can only install one of: symfony/console[v3.4.8, v5.0.7]. - Can only install one of: symfony/console[v3.4.9, v5.0.7]. - Can only install one of: symfony/console[v4.0.0, v5.0.7]. - Can only install one of: symfony/console[v4.0.0-BETA1, v5.0.7]. - Can only install one of: symfony/console[v4.0.0-BETA2, v5.0.7]. - Can only install one of: symfony/console[v4.0.0-BETA3, v5.0.7]. - Can only install one of: symfony/console[v4.0.0-BETA4, v5.0.7]. - Can only install one of: symfony/console[v4.0.0-RC1, v5.0.7]. - Can only install one of: symfony/console[v4.0.0-RC2, v5.0.7]. - Can only install one of: symfony/console[v4.0.1, v5.0.7]. - Can only install one of: symfony/console[v4.0.10, v5.0.7]. - Can only install one of: symfony/console[v4.0.11, v5.0.7]. - Can only install one of: symfony/console[v4.0.12, v5.0.7]. - Can only install one of: symfony/console[v4.0.13, v5.0.7]. - Can only install one of: symfony/console[v4.0.14, v5.0.7]. - Can only install one of: symfony/console[v4.0.15, v5.0.7]. - Can only install one of: symfony/console[v4.0.2, v5.0.7]. - Can only install one of: symfony/console[v4.0.3, v5.0.7]. - Can only install one of: symfony/console[v4.0.4, v5.0.7]. - Can only install one of: symfony/console[v4.0.5, v5.0.7]. - Can only install one of: symfony/console[v4.0.6, v5.0.7]. - Can only install one of: symfony/console[v4.0.7, v5.0.7]. - Can only install one of: symfony/console[v4.0.8, v5.0.7]. - Can only install one of: symfony/console[v4.0.9, v5.0.7]. - Can only install one of: symfony/console[v4.1.0, v5.0.7]. - Can only install one of: symfony/console[v4.1.0-BETA1, v5.0.7]. - Can only install one of: symfony/console[v4.1.0-BETA2, v5.0.7]. - Can only install one of: symfony/console[v4.1.0-BETA3, v5.0.7]. - Can only install one of: symfony/console[v4.1.1, v5.0.7]. - Can only install one of: symfony/console[v4.1.10, v5.0.7]. - Can only install one of: symfony/console[v4.1.11, v5.0.7]. - Can only install one of: symfony/console[v4.1.12, v5.0.7]. - Can only install one of: symfony/console[v4.1.2, v5.0.7]. - Can only install one of: symfony/console[v4.1.3, v5.0.7]. - Can only install one of: symfony/console[v4.1.4, v5.0.7]. - Can only install one of: symfony/console[v4.1.5, v5.0.7]. - Can only install one of: symfony/console[v4.1.6, v5.0.7]. - Can only install one of: symfony/console[v4.1.7, v5.0.7]. - Can only install one of: symfony/console[v4.1.8, v5.0.7]. - Can only install one of: symfony/console[v4.1.9, v5.0.7]. - Can only install one of: symfony/console[v4.2.0, v5.0.7]. - Can only install one of: symfony/console[v4.2.0-BETA1, v5.0.7]. - Can only install one of: symfony/console[v4.2.0-BETA2, v5.0.7]. - Can only install one of: symfony/console[v4.2.0-RC1, v5.0.7]. - Can only install one of: symfony/console[v4.2.1, v5.0.7]. - Can only install one of: symfony/console[v4.2.10, v5.0.7]. - Can only install one of: symfony/console[v4.2.11, v5.0.7]. - Can only install one of: symfony/console[v4.2.12, v5.0.7]. - Can only install one of: symfony/console[v4.2.2, v5.0.7]. - Can only install one of: symfony/console[v4.2.3, v5.0.7]. - Can only install one of: symfony/console[v4.2.4, v5.0.7]. - Can only install one of: symfony/console[v4.2.5, v5.0.7]. - Can only install one of: symfony/console[v4.2.6, v5.0.7]. - Can only install one of: symfony/console[v4.2.7, v5.0.7]. - Can only install one of: symfony/console[v4.2.8, v5.0.7]. - Can only install one of: symfony/console[v4.2.9, v5.0.7]. - Can only install one of: symfony/console[v4.3.0, v5.0.7]. - Can only install one of: symfony/console[v4.3.0-BETA1, v5.0.7]. - Can only install one of: symfony/console[v4.3.0-BETA2, v5.0.7]. - Can only install one of: symfony/console[v4.3.0-RC1, v5.0.7]. - Can only install one of: symfony/console[v4.3.1, v5.0.7]. - Can only install one of: symfony/console[v4.3.10, v5.0.7]. - Can only install one of: symfony/console[v4.3.11, v5.0.7]. - Can only install one of: symfony/console[v4.3.2, v5.0.7]. - Can only install one of: symfony/console[v4.3.3, v5.0.7]. - Can only install one of: symfony/console[v4.3.4, v5.0.7]. - Can only install one of: symfony/console[v4.3.5, v5.0.7]. - Can only install one of: symfony/console[v4.3.6, v5.0.7]. - Can only install one of: symfony/console[v4.3.7, v5.0.7]. - Can only install one of: symfony/console[v4.3.8, v5.0.7]. - Can only install one of: symfony/console[v4.3.9, v5.0.7]. - Can only install one of: symfony/console[v4.4.0, v5.0.7]. - Can only install one of: symfony/console[v4.4.0-BETA1, v5.0.7]. - Can only install one of: symfony/console[v4.4.0-BETA2, v5.0.7]. - Can only install one of: symfony/console[v4.4.0-RC1, v5.0.7]. - Can only install one of: symfony/console[v4.4.1, v5.0.7]. - Can only install one of: symfony/console[v4.4.2, v5.0.7]. - Can only install one of: symfony/console[v4.4.3, v5.0.7]. - Can only install one of: symfony/console[v4.4.4, v5.0.7]. - Can only install one of: symfony/console[v4.4.5, v5.0.7]. - Can only install one of: symfony/console[v4.4.6, v5.0.7]. - Can only install one of: symfony/console[v4.4.7, v5.0.7]. - Installation request for symfony/console (locked at v5.0.7) -> satisfiable by symfony/console[v5.0.7].

How to add new migration version ?

Based on what is described here http://www.laraveldoctrine.org/docs/1.2/migrations/version this might sound naive or irrelevant, but I am new to Laravel and therefore migrations. I apologise if that is the case here.

According to the documentation http://www.laraveldoctrine.org/docs/1.2/migrations/diff I can generate migrations from my entities meta data which is great. My question is how can I add a new version? When I run php artisan doctrine:migrations:diff for my entities I get this version

class Version20170315075736 extends AbstractMigration
{
    /**
     * @param Schema $schema
     */
    public function up(Schema $schema)
    {
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'mysql', 'Migration can only be executed safely on \'mysql\'.');

        $this->addSql('CREATE TABLE user (id INT AUTO_INCREMENT NOT NULL, group_id INT DEFAULT NULL, name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL, phone VARCHAR(255) NOT NULL, status TINYINT(1) NOT NULL, creation_date DATETIME DEFAULT NULL, update_date DATETIME DEFAULT NULL, INDEX IDX_8D93D649FE54D947 (group_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE `groups` (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, creation_date DATETIME DEFAULT NULL, update_date DATETIME DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('ALTER TABLE user ADD CONSTRAINT FK_8D93D649FE54D947 FOREIGN KEY (group_id) REFERENCES `groups` (id)');
    }

    /**
     * @param Schema $schema
     */
    public function down(Schema $schema)
    {
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'mysql', 'Migration can only be executed safely on \'mysql\'.');

        $this->addSql('ALTER TABLE user DROP FOREIGN KEY FK_8D93D649FE54D947');
        $this->addSql('DROP TABLE user');
        $this->addSql('DROP TABLE `groups`');
    }
}

Now I want to add new column and some default meta data rather then modifying existing migration I want to create a new version/migration which should allow me to add just the meta data on top of previous migration. Something like this.

class Version20170315075737 extends AbstractMigration
{
 public function up(Schema $schema)
 {
      $this->addSql('INSERT INTO groups(id, `name`) VALUES(1, "General") ');
 }
}

Now do I need a new version or migration to achieve that?

ErrorException: Undefined variable: migration

I've been having an issue lately with the Laravel Doctrine Migration tool where it basically just fails with this error:

1) DbTests\Migrations\Version20160309144500Test::testMigration
ErrorException: Undefined variable: migration
/home/travis/build/.../vendor/laravel-doctrine/migrations/src/Console/MigrateCommand.php:64
/home/travis/build/.../vendor/illuminate/container/Container.php:507
/home/travis/build/.../vendor/illuminate/console/Command.php:169
/home/travis/build/.../vendor/symfony/console/Command/Command.php:259
/home/travis/build/.../vendor/illuminate/console/Command.php:155
/home/travis/build/.../vendor/symfony/console/Application.php:844
/home/travis/build/.../vendor/symfony/console/Application.php:192
/home/travis/build/.../vendor/symfony/console/Application.php:123
/home/travis/build/.../vendor/illuminate/console/Application.php:64
/home/travis/build/.../vendor/laravel/lumen-framework/src/Console/Kernel.php:107
/home/travis/build/.../vendor/laravel/lumen-framework/src/Testing/TestCase.php:282
/home/travis/build/.../tests/db/Migrations/TestCase.php:37

When you take a look at the file where the issue is happening (laravel-doctrine/migrations/src/Console/MigrateCommand.php), it looks like a code defect introduced by this commit: f9b3381
The $migration variable used on line 64 might not be available if the try/catch surrounding its assignation fails. I'm pretty sure something is wrong somewhere.