You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
while investigating some differences reported by the doctrine:migration:diff command I figured out that there is every time a diff is reported for tables containing foreign keys because of ManyToOne relations. when inspecting the generated migration file I've seen that the up method contains foreign keys while the down method does not. as far as I could see the code sometimes checks if foreign keys are supported before generating the relevant statements and sometimes not.
as foreign keys are a feature that can be turned on/off for an SQLite database it probably makes sense to replace the hardcoded false in SqlitePlatform in method supportsForeignKeyConstraints with a call to PRAGMA foreign_keys; where the result of 0 means it is disabled so the method should return false while the result 1 should return true.
additionally, the getAlterTableSQL in SqlitePlatform should probably check if foreign keys are supported to generate the correct statements not containing the foreign keys. currently, they are generated regardless if SQLite supports it or not.
Current behaviour
table diff migration generates a migration containing foreign keys for SQLite even if the method supportsForeignKeyConstraints returns every time false.
How to reproduce
create two entities with a ManyToOne relation
run symfony console doc:mig:diff --from-empty-schema
run symfony console doc:mig:mig
run symfony console doc:mig:diff
step 4 now generates a diff containing foreign key statements where I actually would expect that nothing is created
Expected behaviour
omit the foreign key statements in the create table statement for a diff
OR
determine if SQLite supports foreign keys so that the check is database feature dependent
OR
add checks if foreign keys are supported in more places which are currently assume they are supported (mainly in the area for the TableDiff handling
The text was updated successfully, but these errors were encountered:
In my understanding, SQLite reporting that it doesn't support foreign keys is a workaround for #4243. Somebody needs to figure out how to address the FK introspection issue without introducing a BC break.
Bug Report
Summary
while investigating some differences reported by the
doctrine:migration:diff
command I figured out that there is every time a diff is reported for tables containing foreign keys because ofManyToOne
relations. when inspecting the generated migration file I've seen that the up method contains foreign keys while the down method does not. as far as I could see the code sometimes checks if foreign keys are supported before generating the relevant statements and sometimes not.as foreign keys are a feature that can be turned on/off for an SQLite database it probably makes sense to replace the hardcoded
false
inSqlitePlatform
in methodsupportsForeignKeyConstraints
with a call toPRAGMA foreign_keys;
where the result of0
means it is disabled so the method should returnfalse
while the result1
should returntrue
.additionally, the
getAlterTableSQL
inSqlitePlatform
should probably check if foreign keys are supported to generate the correct statements not containing the foreign keys. currently, they are generated regardless if SQLite supports it or not.Current behaviour
table diff migration generates a migration containing foreign keys for SQLite even if the method
supportsForeignKeyConstraints
returns every timefalse
.How to reproduce
ManyToOne
relationsymfony console doc:mig:diff --from-empty-schema
symfony console doc:mig:mig
symfony console doc:mig:diff
step 4 now generates a diff containing foreign key statements where I actually would expect that nothing is created
Expected behaviour
omit the foreign key statements in the create table statement for a diff
OR
determine if SQLite supports foreign keys so that the check is database feature dependent
OR
add checks if foreign keys are supported in more places which are currently assume they are supported (mainly in the area for the
TableDiff
handlingThe text was updated successfully, but these errors were encountered: