for use when a test class has a setUpTestData() method which uses
variables set up in the setUpClass() method.
Change base teams API test class to use the context manager.
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.
When capa problem rendering was moved to happen inline on courseware
page loads, we started executing many more Mako templates on sequences
with large numbers of thse problems. To help offset this, we're caching
the context generation (it showed up as the easiest piece of low
hanging fruit on profiles of the courseware index page).
[PERF-261]
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]
The get_or_create function is vulnerable to race conditions in MySQL, which can
cause the model LoginFailure to, in some cases, have more than one row for the
same user, breaking the login for that user.
Addinf functionality to expect and clean the error by deleting extra rows (by
oldest lockout date), leaving just one entry and allowing the user to login.
Replayed and squashed by @efischer19, initially commited by @laq
