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
Prior to #6732, the name for the index supporting a foreign key constraint was generated from the exact values of the column names as specified by the user (e.g. id or `id`). In the new implementation, only the actual name is used (id), hence the change. We cannot (and don't want to) preserve the exact values of the quotes in the new implementation because they are just part of the syntax and shouldn't be taken into account. `A` and "A" (which both mean "quoted A") should not yield different hashes.
An even more proper implementation should use the value of the identifier normalized for the target platform, e.g. for Oracle, names a, A and "A" should yield the same hash.
I'm not documenting the upgrade path for this change yet because I want to clarify a few more details:
Whether this is indeed a breaking change (if the DBAL can detect and handle the index change, we should consider it just a necessary migration).
What steps can the users take to proactively handle this change (e.g. temporarily, explicitly specify index names).
It is possible that at some point we will get rid of auto-generated names and delegate that to the underlying database (that would be ideal and already works if a constraint without a name is passed to the Table constructor).
The text was updated successfully, but these errors were encountered:
Prior to #6732, the name for the index supporting a foreign key constraint was generated from the exact values of the column names as specified by the user (e.g.
id
or`id`
). In the new implementation, only the actual name is used (id
), hence the change. We cannot (and don't want to) preserve the exact values of the quotes in the new implementation because they are just part of the syntax and shouldn't be taken into account.`A`
and"A"
(which both mean "quotedA
") should not yield different hashes.An even more proper implementation should use the value of the identifier normalized for the target platform, e.g. for Oracle, names
a
,A
and"A"
should yield the same hash.I'm not documenting the upgrade path for this change yet because I want to clarify a few more details:
Table
constructor).The text was updated successfully, but these errors were encountered: