CRM-20533 - Drop false indices directly from update indices button #10908
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.
Overview
Delete false indices while updating missing indices button along with displaying it on system status page.
Before
getMissingIndices
function which return missing + false indices.After
Update Indices
button instead of asking users to do so.$dropFalseIndices
param ingetMissingIndices()
which deletes false indices to ensure all indexes returned from this function is not present in civi tables.Update Indices
button.Technical Details
The actual issue here was - on 4.7 upgrade some existing indices were deleted. Note that: there is no issue on complete deletion of these indices. But issue arises only when one of the column in the key index is removed or the order of the column mismatches the definition provided in the xml file.
This PR makes sure to delete non-FK indices from the table. Not sure, but I haven't come across the situation where FK index has a missing column. To all the sites I upgraded, there always was the case where normal indexes were unordered or missing some of the column names.
Hence, dropping FK like https://github.com/civicrm/civicrm-core/pull/10414/files#diff-857aa2763691dd851a1423506a99ad65R775 seems non-essential. Also, I recall retrieving details from
information_schema
has bitten us in the past. Eg. CRM-19610?