Juniper introduces a new mysql database that is used by edx-platform to store the state changes of problem modules for every student. These data are stored in the coursewaremodulextended app (as far as I understand). This database is known as the
student_module_history in the edx-platform code base.
ENABLE_CSMH_EXTENDED feature flag has been set to true (which is the default in Juniper), there is no turning back, because it affects the behaviour of the
0011_csm_id_bigint migration from the courseware.
I would like to know if there are specific precautions ot be taken to create this database and to migrate existing MySQL from Ironwood.
The Juniper page on Jira states that “We are looking at doing large migrations for the
courseware_studentmodule table to prevent running out of primary keys. These will likely be large, semi-manually done migrations on CSM and it’s history table(s). Nothing is settled yet, but if we get this in before Juniper we will need to share our runbooks for anyone upgrading to it.” (cc @bmedx)
I wonder if this comment concerns the edxapp_csmh database?
I found a couple migration scripts in the configuration repository that lead me to believe that special precautions need to be taken when upgrading. On the other hand, these scripts date back from 2016…
I have faced the following error when viewing the courseware in the LMS:
django.db.utils.ProgrammingError: (1146, "Table 'openedx_csmh.coursewarehistoryextended_studentmodulehistoryextended' doesn't exist")
I managed to resolve this error by running some of the migrations specifically on the
./manage.py lms migrate --database=student_module_history coursewarehistoryextended
However I did not find any trace of such a migration command in the configuration playbooks, so I wonder how it all works?