This abstract class contains most of the fields (aside from the id and
foreign key to StudentModule that the subclasses need to manage). It
also provides a get_history method that abstracts searching across
multiple backends.
Move router code to openedx/core
We need to use it from cms and lms.
Ensure aws_migrate can be used for migrating both the lms and cms.
Handle queries directed to student_module_history vs default and the
extra queries generated by Django 1.8 (SAVEPOINTS, etc).
Additionally, flag testing classes as multi_db so that Django will
flush the non-default database between unit tests.
Further decouple the foreignkey relation between csm and csmhe
When calling StudentModule().delete() Django will try to delete CSMHE
objects, but naively does so in the database, not by consulting the
database router.
Instead, we disable django cascading deletes and listen for post_delete
signals and clean up CSMHE by hand.
Add feature flags for CSMHE
One to turn it on/off so we can control the deploy.
The other will control whether or not we read from two database tables
or one when searching.
Update tests to explicitly use this get_history method rather than
looking directly into StudentModuleHistory or
StudentModuleHistoryExtended.
Inform lettuce to avoid the coursewarehistoryextended app
Otherwise it fails when it can't find features/ in that app.
Add Pg support, this is not tested automatically.
This is a clone (copy) of CSMH's declaration and methods with an added
id of UnsignedBigInAutoField
We should be able to delete the save_history code, but needs testing.
Add error logging when capa failures happen
Put StudentModuleHistory into its own database
Bump out the primary key on CSMHE
This gives us a gap to backfill as needed.
Since the new table's pk is an unsigned bigint, even for people who don't
consolidate CSMH into CSMHE, the lost rows are unlikely to matter.
Remove StudentModuleHistory cleaner
By default, migrations are applied as they always have been. Exporting DISABLE_MIGRATIONS=1 or passing --disable-migrations to Paver commands will create tables directly from apps' models.
Before this commit, calling the student_view on a capa problem would
cause it to render an empty placeholder <div>, wait for the
DOMContentLoaded event to be fired, and then make AJAX requests to the
the problem_get handlers to retrieve the HTML it needed to render the
actual problems. This can significantly increase the end user load
times for pages, particularly when there are many problems in a
vertical.
This commit takes a very conservative approach and has the server side
add the rendered HTML into a new data-content attribute on the <div>
enclosing the problem. When Capa's JS initialization runs, it grabs
from that data-content attribute rather than reaching over the network
for an AJAX request.
I had attempted to make it somewhat smarter and push the rendered
problem straight into the document instead of relying on the
data-content attribute. This was faster, and should be our long term
goal. However, it caused odd bugs, particularly around MathJAX
rendering, and I never quite tracked the issue down. I'm still going
forward with these changes because it's significantly better than the
current situation that students have to deal with, and we can make the
JS more performant in a future iteration.
[PERF-261]
