-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Migrations not ever in sync with the DB #3391
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
What database and version are you using? |
Looks like doctrine/orm#6565. |
i have similar issue with PostgreSQL
In only one entity! Other entities with absolutely same config looks great :) final class Version20180809093821 extends AbstractMigration
{
public function up(Schema $schema) : void
{
// this up() migration is auto-generated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');
$this->addSql('ALTER TABLE message ALTER created_at TYPE TIMESTAMP(0) WITHOUT TIME ZONE');
$this->addSql('ALTER TABLE message ALTER created_at DROP DEFAULT');
}
public function down(Schema $schema) : void
{
// this down() migration is auto-generated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');
$this->addSql('ALTER TABLE message ALTER created_at TYPE TIMESTAMP(0) WITHOUT TIME ZONE');
$this->addSql('ALTER TABLE message ALTER created_at DROP DEFAULT');
}
} # Message.php
...
/**
* @ORM\Column(type="datetime_immutable")
*
* @var \DateTimeImmutable
*/
private $createdAt;
... # message DDL (generated by PHPStorm Database module)
create table message
(
...
created_at timestamp(0) not null,
...
) |
@electricBonfire we need to know the exact versions of the database and DBAL. The latter is really important, since it's where the comparison is done. Knowing what's the DDL registered on the DB would also be useful. |
same here
|
Any progress on this issue? We have a similar effect here. doctrine/migrations: 1.8.1 MySQL 5.7.24 |
In my case - boolean fields were changed to |
I've had the same issue with doctrine/dbal 2.9.2. |
i'm having the same problem for multiple column types with mariadb 10.3.11 and current latest dbal release with php 7.2 |
Hi everyone,
I started another project a month ago with same vendor versions, which had no problems to generate migrations : The main difference was in the database used. After switching the database used on the new project to 10.1 instead of 10.3, the problem disappeared. At least the problem is not a problem anymore for my use case, I hope it can help you in understanding the source. |
Having the exact same problem than @dvc with doctrine/dbal 2.9.2, doctrine/doctrine-migrations-bundle 2.0.0 and PostgreSQL 11.2 on x86_64-pc-linux-musl, compiled by gcc (Alpine 8.3.0) 8.3.0, 64-bit |
Same problem here with 10.1.37-MariaDB using InnoDB, doctrine/dbal 2.9.2, orm 2.6.3 and migrations 2.1.0 |
Some issue here only happens on MariaDB, projects that run on Postgres generate clean migrations |
Hi! Got this after upgrading to DBAL 3.3.1 (from DBAL 2) I've got an empty
Apparently something is angry at my collation settings...
When I run
So why does it regenerates the same migration ad libitum? |
Hi, Same problem for me with MySQL 5.7 version? The function up() of the migration file is empty and the function down() look like :
Is it a bug ? |
It definitely is, but I'm not sure the problem lies with DBAL directly. I started breakpointing the other day and noticed that in Interestingly, this is the case with DBAL 2 and 3. It's just not interpreted in the same way by the Edit: No I was wrong, I can AND can't reproduce the bug with doctrine/migrations-bundle:3.2.1, so it's really in dbal. I'll check from which version it appeared. Currently testing dbal:3.2.0 without issue. |
OK so I tested all the releases of
|
I opened a new issue because that one was old and maybe out of sight. #5243 |
Thanks for your issue opened, hope it will be fix soon |
@fdiedler in the meantime you can try locking your dbal version to something that works. |
@Pixelshaped It is strange, I do not have any reference to doctrine/dbal nor doctrine/orm in my composer.json
Maybe it is "included" by another package like framework-bundle ? |
@fdiedler |
@Pixelshaped I just added the doctrine/dbal and blocks to version 3.2.2 and it works when I do migrations:diff :) |
But given your requirements, your project seems simple enough that this issue is probably widespread and will be fixed very soon. (in which case you'll be able to cease to require dbal explicitly) |
@Pixelshaped Thanks for the explanation. There are many dependencies with dbal :
My project is big but I removed a lot of things in my composer.json before posting it here. Hope this bug will be fixed soon. And thanks for the trick, now it works well (but with a lock version and I really do not like that ^^) |
Could you check if this solves the problem: app_doctrine.dbal.schema_filter:
class: Doctrine\Bundle\DoctrineBundle\Dbal\RegexSchemaAssetFilter
arguments: [ '#^(?!(doctrine_migration_versions)$).*#' ]
tags:
- { name: doctrine.dbal.schema_filter } |
Support Question
I am running a symfony 4 project using doctrine and mysql.
I have been running into an issue where the
doctrine:migrations:diff
continuously createsmigrations
regardless of whether the mapping data has changed since lastdiff / migration
For example
If I drop my database, remove all of my migration files, create a new blank db, run
./bin/console doctrine:migrations:diff
and then./bin/console doctrine:migrations:migrate
It creates my database structure. Then without modifying code I run./bin/console doctrine:migrations:diff
again and I get a new migration file altering many of the tables.Here is the initial diff:
and the second diff:
As you can see the first diff creates the table
oauth_access_token
and sets the columnuser_id INT DEFAULT NULL
Then the second diff tries to modify the table
ALTER TABLE oauth_access_token CHANGE user_id user_id INT DEFAULT NULL
Also, If I run
./bin/console doctrine:migrations:diff
./bin/console doctrine:migrations:migrate
and then./bin/console doctrine:schema:validate
I get:Mapping
[OK] The mapping files are correct.
Database
[ERROR] The database schema is not in sync with the current mapping file.
The text was updated successfully, but these errors were encountered: