Deprecate SchemaDiff::toSql() and SchemaDiff::toSaveSql() #5766
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.
TableDiff::getName()
(Deprecate not passing $fromColumn to TableDiff #5678), implementing the SQL-related methods makes the diff (which is a value object) depend on the infrastructure. It should be the other way around.DROP
statements from the generated schema migration SQL is a poor-man solution to dealing with the objects not owned by the DBAL. It has the following downsides:AbstractSchemaManager#_getPortableTableColumnList()
cannot process functional indexes defined in MySQL #5306).toSaveSql()
method and the corresponding$saveMode
parameter names make absolute no sense.SchemaDiff::toSaveSql()
. This method is absolutely untested, and I'm not talking about a unit test that confirms that the flag is respected. I'm talking about the integration testing of the scenarios for which the method was implemented in the first place.Instead of using
SchemaDiff::toSaveSql()
for discarding schema changes in 3rd-party database objects (if that's the case), it is recommended to use asset filtering.