The progress page did a number of things that make performance terrible for
courses with large numbers of problems, particularly if those problems are
customresponse CapaModule problems that need to be executed via codejail.
The grading code takes pains to not instantiate student state and execute the
problem code. If a student has answered the question, the max score is stored
in StudentModule. However, if the student hasn't attempted the question yet, we
have to run the problem code just to call .max_score() on it. This is necessary
in grade() if the student has answered other problems in the assignment (so we
can know what to divide by). This is always necessary to know in
progress_summary() because we list out every problem there. Code execution can
be especially slow if the problems need to invoke codejail.
To address this, we create a MaxScoresCache that will cache the max raw score
possible for every problem. We select the cache keys so that it will
automatically become invalidated when a new version of the course is published.
The fundamental assumption here is that a problem cannot have two different
max score values for two unscored students. A problem *can* score two students
differently such that they have different max scores. So Carlos can have 2/3 on
a problem, while Lyla gets 3/4. But if neither Carlos nor Lyla has ever
interacted with the problem (i.e. they're just seeing it on their progress
page), they must both see 0/4 -- it cannot be the case that Carlos sees 0/3 and
Lyla sees 0/4.
We used to load all student state into two separate FieldDataCache instances,
after which we do a bunch of individual queries for scored items. Part of this
split-up was done because of locking problems, but I think we might have gotten
overzealous with our manual transaction hammer.
In this commit, we consolidate all state access in grade() and progress()
to use one shared FieldDataCache. We also use a filter so that we only pull
back StudentModule state for things that might possibly affect the grade --
items that either have scores or have children.
Because some older XModules do work in their __init__() methods (like Video),
instantiating them takes time, particularly on large courses. This commit also
changes the code that fetches the grading_context to filter out children that
can't possibly affect the grade.
Finally, we introduce a ScoresClient that also tries to fetch score
information all at once, instead of in separate queries. Technically, we are
fetching this information redundantly, but that's because the state and score
interfaces are being teased apart as we move forward. Still, this only
amounts to one extra SQL query, and has very little impact on performance
overall.
Much thanks to @adampalay -- his hackathon work in #7168 formed the basis of
this.
https://openedx.atlassian.net/browse/CSM-17
* added generate certificates task and bok choy tests
* added unit tests
* changes based feedback and improved acceptance test
* Change header text
* changes based on feedback on 24/6
* added task_id to api output
* fixed broken test
* Remove "Instructor" from strings, per Docs team
* Fixed flaky entrance exam test
- added the abstract and concrete layers of enrollment report provider
- created a celery task.
-added the button in the e-commerce reports section
added the enrollment data backend
added the payment data and start writing the test cases.
updated the code with the feedback suggestions and wrote some test cases.
- all the downloadable reports are now visible in the ecommerce download section.
Pending instructor tasks is also visible in the ecommerce section
added the fields in the user profile information
changed the report store configuration key
added the new http endpoint for financial reports to add more permissions for finance_admin to access.
fix quality issues
added test cases to check csv content data
rebased with master and resolved conflicts
changed the log messages
added the changes as per code clintonb suggestions during code review
updated the test cases for the finance_admin decorator
changes suggested by clinton.
Created and moved Table level filters to the Custom Manager for the CourseEnrollment model.
ecommerce.js file was loaded twice in the instructor_dashboard.js fixed the issues
added the registration code column in the csv
added the full gender in the csv file
Update data sources and add display name translations for the report columns
fix meta name
Make sure the reports section does not appear on non whitelabel courses
pylint fixes
expand out enumerated values
As some i18n features need ```ugettext``` or its shorcut ```_``` to be called on a non-string-literal, so the pylint check of ```translation-of-non-string``` should be explicitly disabled in such situations.
Conflicts:
lms/djangoapps/courseware/courses.py
lms/djangoapps/instructor_task/api.py
refined entrance exam student attempts reset
Quality improvements 1/16
added rescore, delete state and task history functionality
added unit tests for entrance exam reset attempts
added unit tests for re scoring of entrance exam and task history
improved test coverage
Got rid of pep violation
feedback changes and added jasmine test
added more jasmine tests for Javascript changes
added bok-choy tests for UI changes
replaced input containing <p> tags with <label>
Removed ee element assertions to avoid js error
Added call to super.setUp()
changes based on feedback on 2/18
Writing tests in JS instead of coffee script
commit related to skip entrance exam 2/13
fixed bad-continuation quality error
fixed broken bok-choy test
changes based on feedback on 2/18
added js tests and removed coffee script tests
fixed broken bok-choy and unit tests
changes left while rebasing
rephrase test titles
do not need these libs
changes based on feedback on 2/24
changes text which was left
Changes based on feedback on 3/3
The existing pattern of using `override_settings(MODULESTORE=...)` prevented
us from having more than one layer of subclassing in modulestore tests.
In a structure like:
@override_settings(MODULESTORE=store_a)
class BaseTestCase(ModuleStoreTestCase):
def setUp(self):
# use store
@override_settings(MODULESTORE=store_b)
class ChildTestCase(BaseTestCase):
def setUp(self):
# use store
In this case, the store actions performed in `BaseTestCase` on behalf of
`ChildTestCase` would still use `store_a`, even though the `ChildTestCase`
had specified to use `store_b`. This is because the `override_settings`
decorator would be the innermost wrapper around the `BaseTestCase.setUp` method,
no matter what `ChildTestCase` does.
To remedy this, we move the call to `override_settings` into the
`ModuleStoreTestCase.setUp` method, and use a cleanup to remove the override.
Subclasses can just defined the `MODULESTORE` class attribute to specify which
modulestore to use _for the entire `setUp` chain_.
[PLAT-419]
