-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DBAL-1063] Allow defining duplicate indexes on a table #764
Conversation
Hello, thank you for creating this pull request. I have automatically opened an issue http://www.doctrine-project.org/jira/browse/DBAL-1102 We use Jira to track the state of pull requests and the versions they got |
Duplicate indexes are considered indexes that pass ``isFullfilledBy()`` or ``overrules()`` | ||
in ``Doctrine\DBAL\Schema\Index``. | ||
This is required to make the index renaming feature introduced in 2.5.0 work properly and avoid | ||
race conditions in the ORM schema tool / DBAL schema manager which pretends users from updating |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're not race conditions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just "issues" is fine
[DBAL-1063] Allow defining duplicate indexes on a table
Backported into |
This PR removes silent dropping of "duplicate" indexes on a table if two indexes fulfill each other or one overrules the other.
This is necessary to make detection of renamed indexes work properly (introduced in 2.5). Currently there are situations where false positive index renamings are detected because of race conditions.
Example
An ORM entity contains an association which adds a foreign key constraint to the underlying table. Foreign key constraints always create implicit indexes on the particular columns.
The entity also contains a mapping for a custom named index fulfilling the foreign key column(s).
The ORM schema tool first adds the foreign key constraint to the table, implicitly creating an index. Afterwards it adds the custom named index which is dropped silently by the table instance because it is considered a "duplicate".
So the table instance created by the schema now contains the auto generated index but not the custom named one.
When using the schema tool to update the schema, the DBAL schema manager is utilized to create the "online" schema. The schema manager detects two indexes in the database, the auto generated one and the custom named one (manually created by the user).
When the schema manger creates the table instance it eventually adds the custom named index first which results in the auto generated index being dropped silently.
When comparing both "offline" and "online" schema, the comparator detects an index rename which actually is none.
This leads to failing
DROP INDEX
andCREATE INDEX
SQL.Besides this issue "duplicate" indexes are totally legit and DBAL should not decide whether or not to create an index. This should be user responsibility.
This implementation is much more transparent and less error prone and opens up more flexibility for the user to define indexes on tables.
/cc @flack @Ocramius @beberlei