Closed SalvatorePollaci closed 2 years ago
I think that the error messages that you get in the 2nd case is due to the fact that the Mig Bundle uses \Doctrine\DBAL\Schema\AbstractSchemaManager::listTables
to determine if its tables are present in the db (if not, it tries to create them on the fly).
Apparently, by adding the kalipomigrations* tables to the schema_filter
, they disappear from the SchemaManager.
Otoh, if you don't, Doctrine messes up those tables.
I will have to investigate this a bit - am a bit rusty here...
Ok, at first sight the quick fix is to use the filter-expression
parameter on the command-line when running doctrine:migrations:diff
. Would you be able to test?
ps: asked the same question on the Doctrine DBAL tracker: https://github.com/doctrine/dbal/issues/3460
@gggeek I just tried the filter-expression
workaround and I can confirm it is working:
bin/console doctrine:migrations:diff --filter-expression='~^(?!ez|kaliop_migrations)~' --env=prod
This workaround is more than sufficient for my current needs but it would be great to have a bug fix like the one proposed by Ocramius.
Thanks
Good to know. I will start by adding this info in the readme. As for the suggested fix: the problem I see with it is that I can not let this bundle overtake by default a service that some other bundle or app code might have customized. What I could do is f.e. add a class that implements the modified service and leave it commented out in services.yml, with appropriate instructions on how to enable it. That is better than nothing but, by experience, not something that most developers would easily discover on their own...
What I could do is f.e. add a class that implements the modified service and leave it commented out in services.yml, with appropriate instructions on how to enable it. That is better than nothing but, by experience, not something that most developers would easily discover on their own...
Yes I agree with you that it's not the best of solutions. But if such instructions are given in the main readme file(e.g. troubleshooting section) I think that would be more than sufficient, or at least for me it would be.
I added one paragraph about this is the main Readme, see: https://github.com/kaliop-uk/ezmigrationbundle/commit/0b35debe3a70c643579cb981a852706c47592943.
I will downgrade this ticket from bug to enhancement and keep it open, in case one day there is time to implement the custom doctrine loader...
@gggeek Seems ok to me
It seems that eZ Migration Bundle is not compatible with Doctrine Migrations Bundle.
Scenario 1 - Doctrine Standard Config
When I run:
the generated migration file tries to DROP and CREATE the 'kaliop_migrations' table.
Scenario 2 - Filter out kaliop_migrations in schema_filter doctrine config option
Whatever ez migration bundle command I run, for example:
I get the following error message: