Update generated diff to match ORM schema diff #1488
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Ports doctrine/orm#7875 into Migrations to improve consistency between queries generated by Migrations diff and the ones generated by the ORM schema update/validate commands. In most cases, the queries where already identical, but in some rare cases (like #1487), the migrations generated from diff did not contain the same queries as the ORM schema update and validate commands.
It also removes filtering the schema generated from metadata (
$toSchema) using DBAL'sschemaAssetsFilterand thedoctrine.dbal.schema_filterconfig, which should only be used to exclude tables in the schema generated from the existing database ($fromSchema- DBAL and DoctrineBundle already cover this). This might be considered a minor BC-break, but if the metadata contains unwanted tables, they shouldn't be included in the mappings in the first place.The decoration of the existing
schemaAssetsFilterfrom the DBAL configuration is done in doctrine/orm#7875 to whitelist assets present in the$toSchemaso that they don't get removed from the$fromSchemaby the defaultschemaAssetsFilter(usually based on thedoctrine.dbal.schema_filterconfig) - a difference which would lead to always generatingCREATE TABLEqueries.I think this last part is best tested in a functional/integration test, but I would need some guidance on how to set it up.
If it's a wanted change, I can also add a note to
UPGRADE.md, depending on the branch it would be included in and if it's considered a minor BC break.