Doctrine Migrations for Laravel
laravel-doctrine / migrations Goto Github PK
View Code? Open in Web Editor NEWIntegration with Doctrine2's migrations package for Laravel
License: MIT License
Integration with Doctrine2's migrations package for Laravel
License: MIT License
# Package version, Laravel version
Laravel Framework 5.5.33
laravel-doctrine/migrations": 1.1.7
laravel-doctrine/orm": 1.4.3
php artisan doctrine:migrations:version --all --add
should add all versions
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
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.
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?
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
Hi! Please support for Laravel ver. 8.x 👍
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.
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.
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.
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.
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 |
When running artisan doctrine:migrations:diff
it's always creates migration that contains changes to sessions
table.
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
SESSION_DRIVER=database
to .env
artisan session:table
artisan migrations:migrate
xml
mappings)artisan doctrine:mapping:import --namespace=Your\\Namespace\\ xml Your/Mappings/Folder
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')
],
]
],
Running artisan doctrine:migrations:diff
gives error with message No changes detected in your mapping information.
Like on screenshot
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
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
php artisan doctrine:migrations:reset
should reset the database... but instead it drops the migrations table first... ?
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
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...
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.
Currently only the migration notes are displayed. But any other output from the base doctrine migrator won't be written to console.
It would be nice to see the extra output from doctrine. I made a quick, dirty solution to show the difference.
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->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.
The command could also pass it's output handler to the ConfigurationProvider::getForConnection()
method.
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!
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?
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.
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).
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.
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
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?
Laravel Framework 5.5.33
laravel-doctrine/migrations": 1.1.9
laravel-doctrine/orm": 1.4.3
php artisan doctrine:migrations:version --all --add --no-interaction
should add all versions without asking for confirmation
php artisan doctrine:migrations:version --all --add --no-interaction
Migration cancelled!
I'm going to submit a PR with a viable solution
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:
Is there a way to add a "ignore table list" in the config file?
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
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?
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.
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?
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
.
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].
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
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?
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.
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.
I have https://github.com/nWidart/laravel-modules this package, and i want to registered all migrations with ServiceProvider. How to make it???
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?
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
Currently working around this by aliasing the new release in my composer.json file:
"laravel-doctrine/orm": "1.3.0 as 1.2.10",
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?
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?
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!
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
$ 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.
Subject.
For add the ability to auto create migrations in a folder by month and year.
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
Current signature:
migrations/src/Console/MigrateCommand.php
Lines 18 to 28 in f1292c3
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.
--query-time
is ignored if there is no value passed to it. But any value passed to is treated as true.
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.
php artisan doctrine:migrations:migrate --dry-run --query-time
php artisan doctrine:migrations:migrate --dry-run --query-time='random string'
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
.
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?
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?
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"
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).*$/',
],
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 |
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.
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.