doctrine:schema:validate returns DROP TABLE doctrine_migration_versions; #1406
Comments
|
+1: |
derrabus
changed the title
|
Somebody posted a workaround for Symfony applications relying on the Doctrine bundle: doctrine:
dbal:
schema_filter: ~^(?!doctrine_)~Can people here please test? |
|
|
Possible next steps:
|
|
The bug exists on ORM 3.1 with DBAL 3.8 as well, it is not per se a DBAL 4.0 issue. |
|
OK so possible next steps:
If somebody could dump their DBAL schema filter at runtime using the DBAL configuration object on ORM 2 then on ORM 3, it might help. |
|
Can somebody here please confirm that they get the issue with ORM 2 when using the |
No |
|
|
|
This is a real problem for our project, especially for production. because it causes an even bigger problem: |
|
Here is a shell script to trigger both a succeeding workflow with ORM 2.19 and a failing one with ORM 3.0. Script#!/usr/bin/env sh
# Set up new Symfony 7 project
composer create-project symfony/skeleton:"7.0.*" my_test_project
cd my_test_project
# Install Doctrine bundles
composer require --no-interaction "doctrine/doctrine-bundle:~2.11" "doctrine/doctrine-migrations-bundle:~3.3" "doctrine/orm:~2.19" "doctrine/dbal:~3.8"
# Use sqlite for local testing
echo "DATABASE_URL=\"sqlite:///%kernel.project_dir%/var/data.db\"" > .env.local
# Install empty migration. This creates the sqlite database with the doctrine_migration_versions table
bin/console doctrine:migrations:generate
bin/console doctrine:migrations:migrate
# Validate schema: succeeds
bin/console doctrine:schema:validate -v
# Upgrade to ORM 3.*
composer require "doctrine/orm:~3.0"
# Validate schema: fails
bin/console doctrine:schema:validate -vThe difference causing the change is that within the callstack of the command, the variable Backtrace ORM 2.19Backtrace ORM 3.0 |
|
Related PRs:
I think we should leverage asset filtering to do this. If it causes issues with command from |
|
Just remembered this solution that does exactly that (using a dynamic filter). Something better that might benefit not just Symfony users might be to do it directly from code inside |
|
Proposed If you run for example |
|
@gjuric yes, @yapro already established that in #1406 (comment) Can you try the solution in my last command? I'm currently working on integrated the solution from my previous comment in the migrations bundle. |
|
Here is my attempt: doctrine/DoctrineMigrationsBundle#526 |
|
For now, I manually add the migration table to the schema with a doctrine event listener on Here's a gist if anyone interested : https://gist.github.com/Brewal/d0fe0792a69e7e5fdf3fb06898b20d35 |
|
Adding a listener for |
|
If it relies solely on the ORM's event system and not on Symfony or the DoctrineBundle, I can see how it would be superior to the asset filtering solution, in that it could benefit to other frameworks such as Laminas or Laravel as well. @Brewal @stof are you willing to open a pull request? Otherwise I might work on it soon. If I understand properly, the ORM command works by diffing 2 schemas. @FlyingDR's relies on asset filtering at the DBAL level, while Symfony's event system, which means it works only for Symfony (I think? Can @Brewal's solution relies on the ORM event system, which will kick in only for the ORM. I hope we are not forgetting about other cases relying on schema diffing and not relying on the ORM somehow. Are there other pros or cons I'm forgetting ? |
Removing the table from the schemas won't detect changes to |
|
Gave it a try, and I'm starting to see some cons:
I think I'd rather we go with @FlyingDR's solution, where only |
|
I gave it a try as well and ended up opening three PRs where each PR requires the previous one.
I don't believe so as
Hence the choice to remove the table from the comparison schema instead of adding it to the generated (metadata) schema. This doesn't catch changes to One thing that is missing is documentation on how to use #1418 without DoctrineMigrationsBundle. I feel like we can and should add that to the docs of this repository. |
Can you please elaborate on this? I think I might know what you mean, but am not sure. The schema asset filter is kind of hard to work with when you have several filters to add, and that is patched by https://github.com/doctrine/DoctrineBundle/blob/2.11.x/Dbal/SchemaAssetsFilterManager.php, which feels like it could have been contributed to DBAL directly. |
|
ORM's SchemaTool has two methods generating a schema both providing a way to hook into the generated schema before it is returned.
Adding |
|
Ah I see, it's less open because it only allows to remove assets, got it 👍 |
|
Hi I have the same problem, doctrine:schema:validate show database not in sync. If I test the workaround it's ok but I can execute other migrations. I have update my packages but it's always not ok composer show | grep doctrine |
|
+1 with same versions as @devbysb |
|
Not sure where it comes from. |
|
Problem is not here But just switching to the upper version of the ORM, and the issue is back : |
BC Break Report
Summary
When I updated doctrine/orm to version 3.0.0, my CI started to fail due to the doctrine:schema check:validate, which returned DROP TABLE doctrine_migration_versions;
I found that adding schema_filter can fix this problem: "
^(?!doctrine_migration_versions$)" in the dbal configuration, indeed, then the error no longer appears, but after that my migrations stopped tracking the current state and think that at the moment no migration has been performed.In version 3.0, the saveMode argument was removed in \Doctrine\ORM\Tools\SchemaTool::getUpdateSchemaSql and because of this, doctrine:schema:validate tracks deleted tables and returns sql for this action.
Previous behavior
Current behavior
How to reproduce
The text was updated successfully, but these errors were encountered: