Hotfix for OC-639: Database conflict between mentoring and problem_builder #18
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.
Hotfix for OC-639:
Bug details:
The old mentoring XBlock uses South migrations to create a table called
mentoring_answers. The new Problem Builder XBlock uses syncdb to create a table also calledmentoring_answers.Unfortunately, if a new edX instance is spun up and mentoring v1 and Problem Builder are both being installed at the same time (as they are if
requirements/edx/edx-private.txtis used), there will be a database error since the South migration will abort when it finds that the table already exists: https://gist.github.com/maxrothman/3868d5e7ad87533a287cBecause syncdb does nothing if the table already exists, an edX instance could only have both blocks installed as long as mentoring was installed and setup in the DB first.
Fix details:
My proposed fix is just to rename the table in Problem Builder. I've also added a data migration that copies all student answers from the
mentoring_answerstable to the new table, which should prevent any students who may be currently using problem builder from losing data.Consequences:
Recovery:
If someone encountered the error seen in the gist link above, it should be possible to recover with:
(Change
devstackto whatever configuration is being used)