Pre-load the course overviews attached to CourseEnrollments on the
Student Dashboard, if possible. This will only grab the CourseOverviews
that already exist, and will not generate new ones. Any missing
CourseOverviews fall back to the lazily-created one-at-a-time behavior
they've always had. That's mostly because I wanted to optimize for the
common case in the least invasive way possible, and I don't want to get
caught up in locking issues.
There are a number of Django Signals that are on the modulestore's
SignalHandler class, such as SignalHandler.course_published. These
signals can trigger very expensive processes to occur, such as course
overview or block structures generation. Most of the time, the test
author doesn't care about these side-effects.
This commit does a few things:
* Converts the signals on SignalHandler to be instances of a new
SwitchedSignal class, that allows signal sending to be disabled.
* Creates a SignalIsolationMixin helper similar in spirit to the
CacheIsolationMixin, and adds it to the ModuleStoreIsolationMixin
(and thus to ModuleStoreTestCase and SharedModuleStoreTestCase).
* Converts our various tests to use this new mechanism. In some cases,
this means adjusting query counts downwards because they no longer
have to account for publishing listener actions.
Modulestore generated signals are now muted by default during test runs.
Calls to send() them will result in no-ops. You can choose to enable
specific signals for a given subclass of ModuleStoreTestCase or
SharedModuleStoreTestCase by specifying an ENABLED_SIGNALS class
attribute, like the following example:
from xmodule.modulestore.tests.django_utils import ModuleStoreTestCase
class MyPublishTestCase(ModuleStoreTestCase):
ENABLED_SIGNALS = ['course_published', 'pre_publish']
You should take great care when disabling signals outside of a
ModuleStoreTestCase or SharedModuleStoreTestCase, since they can leak
out into other tests. Be sure to always clean up, and never disable
signals outside of testing. Because signals are essentially process
globals, it can have a lot of unpleasant side-effects if we start
mucking around with them during live requests.
Overall, this change has cut the total test execution time for
edx-platform by a bit over a third, though we still spend a lot in
pre-test setup during our test builds.
[PERF-413]
This commit "undoes"a previous hotfix, and allows a cms course_publish
signal to trigger a block_structure update_course_in_cache task, which
is run on an lms worker queue.
Changes:
-exposes ALTERNATE_QUEUE_ENVS
-adds routing layer in celery.py
-moves prior dev_with_worker settings file to devstack_with_worker
-moves course_block api functionality into openedx/core/djangoapps/content/block_structure
By default, disable all caching in tests, to preserve test independence.
In order to enable caching, inherit from CacheSetupMixin, and specify
which cache configuration is needed.
[EV-32]
We don't want to blindly assemble the base CDN URL with whatever an
image URL happens to be, since it might be an absolute URL and now the
result is a broken URL. We take a more selective approach now.
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.
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.
Cached values were leaking across tests, causing difficult to debug errors,
particularly when using Config Models. As part of this work, certain tests
that had query counts that relied on those values being cached needed to
be adjusted up.
Without this change, we'd throw a TransactionManagementError in the case
where we have a race condition and generate multiple CourseOverviewImageSets
for the same CourseOverview concurrently.