Before this change the messages in the message popup would be loaded
onto a page in a random order, based on the speed at which the user's
browser was able to render each template.
This causes the messages to be attached to the page sequentially, after
they have all been rendered asynchronously.
This just deletes all the upgrade steps previous to 3.0.0. Some
small adjustments, like adding missing MOODLE_INTERNAL or tweaking
globals can also be applied when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2015111600 (v3.0.0) as anti-cheating measure.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase.
Removed the concat to generate the uniqueid field for the popup
notifications data. The concat can't be used directly in the SQL because
the syntax changes between databases. The sql_concat helper can't be
used because it assumes all values are database columns (which they
aren't in this case).
Instead I've just removed the uniqueid field because it isn't required
for the union all to work and the field isn't being used by anything.
This should fixed the compatibility issues between databases.
The OR clause in these queries used different sets of columns to select
userid which meant that the indexes that included user id could not be
used.
This change splits the query so that each individual part can use one of
the indexes that includes a userid which speeds them up considerably.
Previously there were a few issues with the code
* We were capturing a promise without then then .then() that came after
it, so our promise wouldn't always be completely resolved by the time
then next piece of code was operating on it
* We weren't catching all errors with .catch()
If there was no conversation found and the method returned early, the
active transaction was not marked as committable and the error was
reported by the request shutdown handler.
Attaching a unit test for the case just because it did not seem to be
covered. I was trying to reproduce the thrown error in the unit test but
it can't be used in this case. The shutdown handler puts the warning
directly into the error_log and it is not guaranteed where such messages
go (depending on the PHP configuration). And we do not even raise it
during the unit test execution (presumably due to noise it would
produce) anyway.
I have broken up the single query that was doing multiple joins on the
messaging and user tables. It no longer does any joins and will instead
query each data set individually.
This may cost more in terms of PHP processing but it will mean that
standard database tunings should be able to handle larger data sets.
For example this function was taking a long time to run on moodle.org
and was causing the MySQL join buffer to overflow.
