-
-
Notifications
You must be signed in to change notification settings - Fork 825
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
CRM-18983. MySQL fatal error on 4.7.8 upgrade due to excess key length. #8605
Conversation
xurizaemon
commented
Jun 21, 2016
•
edited by civicrm-builder
Loading
edited by civicrm-builder
- CRM-18983: CiviCRM DB error on 4.7.8 upgrade
test fails look related. I don't know it helps here but this method 3fe26f4 will cope with already-existing indexes |
👍 to doing schema changes from PHP, was amending the existing work from CRM-17967 where this came from. Thanks for that pointer. Something to document in the developer docs? Are there good reasons to accept PRs which do schema changes in .sql (and thus fail a bit harder)? |
yes please to documenting that - it's fairly new functionality but I can't think of a case where it is NOT better |
Also now that there is the method i have created in the schemahandler class which checks if a specific column for a table already exists makes sense to run things from PHP |
Is this the code that's going to be part of 4.7.10? I want to upgrade to 4.7.9 as soon as I can, but I don't want to end up with a subtly different schema than 4.7.10 is expecting. |
I looks like it's pending a rebase & some QA. The update will need to be adapted to make sure existing DBs are not 'disadvantaged' by it Unless you have a large DB it probably won't matter since running that change will make for a slow upgrade on a large DB- but otherwise you might wind up with it running on more than one upgrade & it won't really matter. If your key length is longer than it needs to be I wouldn't expect any problems - CiviCRM doesn't 'know about' that at run timeI looks like it's pending a rebase & some QA. The update will need to be adapted to make sure existing DBs are not 'disadvantaged' by it Unless you have a large DB it probably won't matter since running that change will make for a slow upgrade on a large DB- but otherwise you might wind up with it running on more than one upgrade & it won't really matter. If your key length is longer than it needs to be I wouldn't expect any problems - CiviCRM doesn't 'know about' that at run time |
I need to make some changes and fix a additional issue due to length change raised in https://issues.civicrm.org/jira/browse/CRM-19100. So closing this PR in favor of #8722 |