Derived table support was altered in MySQL 5.7 changing the way in which
DELETE FROM works in some cases.
This change modifies the way in which deletion occurs by selecting all IDs
and batching them into groups of 1000.
* A method to change the max mark for one question_attempt in the usage
* A method to replace one question in a usage with another, moving the
old question_attempt to the end.
* Methods to set and get metadata (string name value pairs) for each
question_attempt in the usage. This gets stored in the first step in a
way that should not interfere with anything else.
There are several improvements over what we had before:
1. We track all the questions seen in the the student's previous
quiz attempts, so that when they start a new quiz attempt, they get
questions they have not seen before if possible.
2. When there are no more unseen questions, we start repeating, but
always taking from the questions with the fewest attempts so far.
3. A similar logic is applied with variants within one question.
There is lots of credit to go around here. Oleg Sychev's students Alex
Shkarupa, Sergei Bastrykin and Darya Beda all worked on this over
several years, helping to clarify the problem and shape the best
solution. In the end, their various attempts were rewritten into this
final patch by me.
Variant has two purposes. First to determine which version of the
question the student will see. Hence it is used to set up the state
of the quetsion when the question is started. Then the internal state of
the question is saved in the first step.
Once that has been done, the variant number is purely informative, and
just used to break down the statistics.
In some cases (the one I have in mind is qtype_opaque) then there is a
complex randomisation process, which may lead to several inital variant
numbers acutally giving the same version of the question. In this case
it is nice if the question can update the stored variant number, to make
the statistics more meaningful.
The MySQL (& Maria DB) query 'optimizer' was failing to handle this
query, so for that DB only, we give it an equivalent query that it can
get right.
With unit test.
This was breaking with oracle master/master replication. Fortunately all
the places that needed to be changed were private to datalib.php. There
is still some ordering by id there, but only places where we want a
consitent, rather than meaningful, order, so that is OK.
The queries changed by this patch all have subqueries in aggregate
queries that pull out the latest step for a question_attempt. Those
queries used to look for MAX(id) but now they look for
MAX(sequencenumber). This is equivalent (for databases where ids always
increase with time, except for auto-saved steps. In the past, an
auto-saved step might have been considered latest. Now the latest step
will always be one that has been properly processed. You can aruge that
this change is an improvement. Anyway, it is a moot point. All these
queries are only used in reports which are run on completed attempts,
where there will not be any autosaved data.
Plain responses, without files, were getting messed up by the
fix for MDL-39980. Something that looked like an HTML comment was being
appended.
This fix works by avoiding appending anything if there are no files. The
new unit test (which was failing before I fixed the code) confirms that
this works. The other tests should be enough to verify that there are no
regressions.
This parallels question_attempt->minfraction, which allows the
fractional mark to go below zere.
This is needed to allow the certainty-base marking behaviours to work
better.
to question bank
- move cron to clean up old cache records move code and
rename classes
- further review of the quiz reports statistics code
- starting to separate calculations of quiz stats, question stats and
response analysis
- introduce hashcode db field for cached stats convert
- code to use qubaids hashcode for caches
We just drop the old tables (including previous upgrade steps) and
re-create the new ones, because these tables just cache calculated
statistics. No important data is stored in them.
This slighly changes the format for the way answers are stroed in the DB
in the case where there is some HTML content, but no files. This should
not cause any problems.
When doing Each attempt builds on last, we need to copy any response
files into a draft file area, and then re-save them.
While writing the unit test for this, I had to deal with a todo in the
question engine so that questions with files in the response could be
unit-tested.
I also found an fixed a bug with qtype_essay_question::is_same_response
and fixed some notices in the existing essay/manual graded unit tests.
1. Autosave works in some ways just like a normal save. We ultimately
call $behaviour->process_save() to do the work, and create a new step to
hold the data.
2. However, we come in through a completely different route through the
API, starting with separate auto-save methods. This keeps the auto-save
changes mostly separate, and so reduced the chance of breaking existing
working code.
3. When the time comes to store the auto-save step in the database, we
save it using a negative sequence number.
This is a clever trick that not only distinguises these steps, but also
avoids unique key errors when an auto-save and a real action happen
simultaneously. (There are unit tests for these tricky edge cases.)
4. When we load the data back from the database, most of the time the
auto-save steps are loaded back as if they were a real save, and so the
auto-saved data is used when the question is then rendered.
5. However, before we process another action, we remove the auto-saved
step, so it does not appear in the final history.
This adds cron code which looks for question previews that have not been
touched for more than 24 hours, and deletes them.
We try to delete previews immediately. For example if the user clicks
start again, then we immediately delete their previous preview. However,
we can't do that if they just close the preview window. Hence we need
some cron code to clean up old preview that have got left lying around.
Normally, this code will not have much to do, so it will be very fast,
so we can afford to run it every cron.
This has been implemented in such a way that in future it will be easy
to add other cron code to the question bank.
Sadly, to make this work on MySQL, we require a horrible hack in the
already hacky delete_usage_records_for_mysql function.
Also, some MySQL-only code had not been updated.
This problem only affected a small minority of question attempts, like
this:
1. Suppose you have a shortanswer question with correct answer 'Toad'
and some hints.
2. Suppose a student attempts this using the interactive behaviour and
on the first try responds 'Frog', and on the second try responds 'Toad'.
3. Then suppose the teacher edits the question to make 'Frog' correct.
4. Then, when the quiz is regraded, the question_attempt_step for the
second try will need to be deleted. That is where the buggy code was.
The problem was mostly that, in the past, we did not worry if
question_attempt_step.id changed during regrade (because we deleted the
old step row and inserted a new one). However, now that steps can have
associated files, we can't be that slack, becuase the step id is used as
the file itemid.
So, now, we have to update the existing rows during a regrade. We do
this by having the question engine tell the question_engine_unit_of_work
that the step has first been deleted, and then added back. Then we make
the unit-of-work spot that delete + add = update.
This also means that during regrading, we have to pass around some extra
ids so that new steps know the id of the step they are replacing.
Naturally, this requires some quite trickly logic, so I finally got
around to writing unit tests for question_engine_unit_of_work, which is
a good thing.
Along the way I also got around to renaming
question_attempt->set_number_in_usage, which got missed out when
everthing else was renamed to slot ages ago.
Finally, while working on this code, I noticed and fixed some PHPdoc
comments.
1. So we will truncate the question summary to 65000 chars if necessary.
2. Also, fix one minor error in mutlianswer save_question_options.
question_bank::MAX_SUMMARY_LENGTH is not the most logical class to add
the constant to, but it needs to be accessible during upgrade, so I was
lazy and put it there.
