Unfortunately, instrospection.get_table_description runs
select * from course_overview_courseoverview, which of course
does not exist while django is calculating initial migrations, causing
this to fail. Additionally, sqlite does not support information_schema,
but does not do a select * from the table.
Lift the main part of mysql's get_table_description up to the migration itself
and just inspect it directly. Continue to call the API for sqlite.
- adaptation asides to be imported from the XML
- updating SplitMongo to handle XBlockAsides (CRUD operations)
- updating Studio to handle XBlockAsides handler calls
- updating xblock/core.js to properly init XBlockAsides JavaScript
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.
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.
We removed a column in the same release that we removed it
from the model. This creates a gap where the code still looks for
a column which has been dropped until the new code has been deployed.
The initial fix was to put the column back, but that creates a window
during the alterations where views will error.
This noops the 0008 migration and effectively noops 0009 unless you've
run the old migration.
