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.
TNL-4151 had previously been fixed to avoid a flaky condition; however,
that only passed the flaky condition to a later point in the
test. The proper fix is to ensure the page has loaded. Putting the
definition in this method will mean that the page will wait
to load with other functions, such as `DashboardPage.visit()`.
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.
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
