The idea of this report is that administrators can set up pre-defined SQL queries that other people can then go in and execute.
This lets you easily create new reports where there is not already an admin report plugin that does what you want. Naturally formatting is a bit basic, but it is good enough for most things.
Anyway, the OU wanted it, I did it, and now you can have it: http://moodle.org/mod/data/view.php?d=13&rid=2884. Naturally, the download zip file will not be ready until tomorrow.
Tim Hunt
Discussions started by Tim Hunt
Working on my question engine re-write, I have been trying to get my head around what all the different bits of a Moodle question are.
I need to know this, so I can make the code work correctly, but more importantly, there needs to be a clear answers so that it is possible to explain how the quiz works to teachers and students.
This diagram summarises my attempts:
There is a more detailed explanation on Development:Question Engine 2:Overview#What_are_the_parts_of_a_question.3F.
However, I am sure I have overlooked something, so I am posting here in the hope of getting some comments.
I need to know this, so I can make the code work correctly, but more importantly, there needs to be a clear answers so that it is possible to explain how the quiz works to teachers and students.
This diagram summarises my attempts:
There is a more detailed explanation on Development:Question Engine 2:Overview#What_are_the_parts_of_a_question.3F.
However, I am sure I have overlooked something, so I am posting here in the hope of getting some comments.
Moodle in English -> General developer forum -> Databases: Database transactions in Moodle
by Tim Hunt -
For a long time we have avoided using database transactions at all in Moodle, because MySQL/ISAM does not support them.
However, they can often be used in a way that makes things more robust on databases that support them, without causing problems in places that do not use them.
For example, in the code I am working on, I want an insert_question_attempt method, which inserts a whole bunch of related data in the database.
Using database transactions you can ensure that, even if an unexpected exception occurs, either all the rows have been inserted and the method completes normally, or nothing is added to the database, and the method end with the exception being thrown.
(And, if you are on MySQL/ISAM that cannot do transactions, then if an exception is thrown you will end up with half the data written, and there is really nothing you can do about that. That is what I mean by less robust in databases that do not support them.)
Now, actually, my situation is not that simple, because I have another method, insert_question_attempt_step, and in pseudocode they look like this:
function insert_question_attempt() {
function insert_question_attempt_step() {
Now, if you naively try to use transactions here,
function insert_question_attempt() {
function insert_question_attempt_step() {
it will not work, because you are not allowed to nest database transactions.
Now, for a long time, at the OU, we have had a nice solution to this that sam invented. The attached patch is me rewriting that to fit into the Moodle 2.0 database API. It implements nested logical transactions, while only using one real database transaction. Using the patch, insert_question_attempt would look like
function insert_question_attempt() {
(and insert_question_attempt_step similarly), and that will work. A call to insert_question_attempt will either insert everything into the database, or nothing will be inserted. The same contract applies if you call insert_question_attempt_step on its own.
The clever bit about this, which you may not immediately notice, is the fact that we are using the $transaction object. The reason for this is that it automatically detects situations where people write silly code like
Suppose an exception is thrown in the middle of // Do stuff ... Then the commit is never called, and there is no call to rollback anywhere. You might be left with a dangling database transactions. Bad.
Well, the $transaction object has a destructor. When you get to the end of the function, the $transaction will be destroyed (unless you return it, in which case it will be destroyed elsewhere). When the $transaction is destroyed, it checks to make sure that it has been committed or rolled back, and if not, it outputs a debugging() message telling you that you forgot, and then does a rollback.
The patch also has code to check to make sure the transactions are nested properly, which is why a string is passed into the constructor.
So, as I say, we have used this for ages at the OU and it is really nice. I would like this in Moodle core, but obviously that requires discussion. Hence this forum post.
(Note, the attached patch is not tested yet, and there are no unit tests, but it should make it clear exactly what I am proposing.)
However, they can often be used in a way that makes things more robust on databases that support them, without causing problems in places that do not use them.
For example, in the code I am working on, I want an insert_question_attempt method, which inserts a whole bunch of related data in the database.
Using database transactions you can ensure that, even if an unexpected exception occurs, either all the rows have been inserted and the method completes normally, or nothing is added to the database, and the method end with the exception being thrown.
(And, if you are on MySQL/ISAM that cannot do transactions, then if an exception is thrown you will end up with half the data written, and there is really nothing you can do about that. That is what I mean by less robust in databases that do not support them.)
Now, actually, my situation is not that simple, because I have another method, insert_question_attempt_step, and in pseudocode they look like this:
function insert_question_attempt() {
$DB->insert_record(...)
foreach ($steps as $step) {
}foreach ($steps as $step) {
insert_question_attempt_step($step);
}function insert_question_attempt_step() {
$DB->insert_record(...)
foreach ($data as $name => $value) {
}foreach ($data as $name => $value) {
$DB->insert_record(...);
}Now, if you naively try to use transactions here,
function insert_question_attempt() {
$DB->begin_sql();
try {
try {
$DB->insert_record(...)
foreach ($steps as $step) {
$DB->commit_sql();
foreach ($steps as $step) {
insert_question_attempt_step($step);
}$DB->commit_sql();
} catch ($e) {
} $DB->rollback_sql();
throw $e;
}throw $e;
function insert_question_attempt_step() {
$DB->begin_sql();
try {
try {
$DB->insert_record(...)
foreach ($data as $name => $value) {
$DB->commit_sql();
foreach ($data as $name => $value) {
$DB->insert_record(...);
}$DB->commit_sql();
} catch ($e) {
} $DB->rollback_sql();
throw $e;
}throw $e;
it will not work, because you are not allowed to nest database transactions.
Now, for a long time, at the OU, we have had a nice solution to this that sam invented. The attached patch is me rewriting that to fit into the Moodle 2.0 database API. It implements nested logical transactions, while only using one real database transaction. Using the patch, insert_question_attempt would look like
function insert_question_attempt() {
$transaction = $DB->start_transaction('insert_question_attempt');
try {
try {
$DB->insert_record(...)
foreach ($steps as $step) {
$transaction->commit();
foreach ($steps as $step) {
insert_question_attempt_step($step);
}$transaction->commit();
} catch ($e) {
} $transaction->rollback();
throw $e;
}throw $e;
(and insert_question_attempt_step similarly), and that will work. A call to insert_question_attempt will either insert everything into the database, or nothing will be inserted. The same contract applies if you call insert_question_attempt_step on its own.
The clever bit about this, which you may not immediately notice, is the fact that we are using the $transaction object. The reason for this is that it automatically detects situations where people write silly code like
$transaction = $DB->start_transaction('imlazy');
// Do stuff ...
$transaction->commit();
// Do stuff ...
$transaction->commit();
Suppose an exception is thrown in the middle of // Do stuff ... Then the commit is never called, and there is no call to rollback anywhere. You might be left with a dangling database transactions. Bad.
Well, the $transaction object has a destructor. When you get to the end of the function, the $transaction will be destroyed (unless you return it, in which case it will be destroyed elsewhere). When the $transaction is destroyed, it checks to make sure that it has been committed or rolled back, and if not, it outputs a debugging() message telling you that you forgot, and then does a rollback.
The patch also has code to check to make sure the transactions are nested properly, which is why a string is passed into the constructor.
So, as I say, we have used this for ages at the OU and it is really nice. I would like this in Moodle core, but obviously that requires discussion. Hence this forum post.
(Note, the attached patch is not tested yet, and there are no unit tests, but it should make it clear exactly what I am proposing.)
Moodle in English -> Quiz -> Require students to confirm that what they are about to submit is all their own work
by Tim Hunt -
I have been asked to implement this feature for the OU: MDL-20574, copied and pasted below for your convenience.
I was wondering if it was of interest to other people or not. It is yet another setting on the already very long quiz settings form, so I guess we should not add it to the main Moodle release unless it will be useful to a reasonable number of other people too. I guess if you want it, vote for the bug. Or just make your feelings known here.
If this option is selected, then when the student starts a quiz attempt they will initially see a page with a message like
This will be integrated with the screen that ask the student to enter a password, if that is required.
The text there will be stored in Moodle language strings, so if administrators wish to edit it specifically for their site, they can do so using the standard language editing tools.
By default, this will be an 'advanced' setting, and off by default, although like all quiz settings, administrators can change the default, and whether it is advanced on their site.
I was wondering if it was of interest to other people or not. It is yet another setting on the already very long quiz settings form, so I guess we should not add it to the main Moodle release unless it will be useful to a reasonable number of other people too. I guess if you want it, vote for the bug. Or just make your feelings known here.
Quiz option requiring students to tick a 'this is all my own work' plagiarism statement before starting an attempt
Add an option to the quiz settings, in the section 'Extra restrictions on attempts': Show plagiarism statement: [No / Before first attempt / Before each attempt]
If this option is selected, then when the student starts a quiz attempt they will initially see a page with a message like
Plagiarism and cheating are serious academic issues. It is important that the work you are about to submit as part of this quiz is all your own.
[ ] I confirm that this quiz attempt will be all my own work.
( Continue)
[ ] I confirm that this quiz attempt will be all my own work.
( Continue)
This will be integrated with the screen that ask the student to enter a password, if that is required.
The text there will be stored in Moodle language strings, so if administrators wish to edit it specifically for their site, they can do so using the standard language editing tools.
By default, this will be an 'advanced' setting, and off by default, although like all quiz settings, administrators can change the default, and whether it is advanced on their site.
I have just written some more stuff on the docs page Development:Goals_of_an_online_assessment_system.
The new bits start at section 2 (The components of an online assessment system) which is a copy an paste of the answer I gave here to a question that was asked by Chris Collman recently.
Section 4 (A roadmap for computer-marked assessment in Moodle) is probably the most interesting bit. It is my attempt to summarise what I think are the major things we need to address in future. Although I call this a roadmap, there is not time-scale for any of it. As ever, things will only happen as and when someone has time and inclination to do something.
Naturally, I hope this provokes discussion. I already know what I think. I am much more interested to know what you think.
The Moodle quiz must always be a tool for teaching, not a toy for software developers, and I am sure I have forgotten some things, so please let us know your ideas.
The new bits start at section 2 (The components of an online assessment system) which is a copy an paste of the answer I gave here to a question that was asked by Chris Collman recently.
Section 4 (A roadmap for computer-marked assessment in Moodle) is probably the most interesting bit. It is my attempt to summarise what I think are the major things we need to address in future. Although I call this a roadmap, there is not time-scale for any of it. As ever, things will only happen as and when someone has time and inclination to do something.
Naturally, I hope this provokes discussion. I already know what I think. I am much more interested to know what you think.
The Moodle quiz must always be a tool for teaching, not a toy for software developers, and I am sure I have forgotten some things, so please let us know your ideas.