Basically, I want to do and environment check
count_records('questions', 'qtype', 'rqp') == 0
Is this possible at the moment, or does it require me to extend the environment checking stuff first?
To explain in more detail what is going on: the RQP question type was a really cool idea, but it has not worked since Moodle 1.6, and is not maintained. I am working on a sort-of Son-of-RQP called Opaque. I am about to check the opaque question type into contrib, and I think at the same time, I should move the rqp question type out of core and into contrib too.
It seemed appropriate to warn people if they had any rqp questions in their database before doing this upgrade. (Since that is what Eloy suggested to Jamie instead of this admin report.)
In reply to Tim Hunt
Re: How does the pre-upgrade environment check work?
Hi Tim,
I really think that we must add that sort of stuff to the environmental checks. It would allow moodlers to know more (and better) about how their servers will support future Moodle versions without having to discover it suddenly (on upgrade).
To do so, I would propose something like this:
1) Create one new 'CUSTOM_CHECKS' section in the environmental XML files. I will contain on list of 'CUSTOM_CHECK' declarations, each one pointing to one library and one function to be executed. Each check will have the "standard" level (optional/required) and the corresponding FEEDBACK section pointing to the message to be displayed.
2) Create the check functions. All them should share a similar structure, returning true/false depending of how the check has worked and with one unique parameter by reference of class "environment_results" that can be modified by the function itself (like current "bypass" and "restrict" functions. I would create all the functions starting by, say "environment_" to avoid arbitrary function execution and so on.
3) Modify environmentlib to be able to process that new section, calling to the defined functions, processing results and so on. It will inform gracefully if some function isn't found and so on...
4) Once 100% tested, backport the lib, the check functions and the xml file to stable branches.
But yes, +1 to add as many checks as necessary in the environmental stuff. If somebody wants to start to discuss/develop about the basic idea described above it will be great! If nobody starts it, I think I could start doing something in 1-2 weeks from now.
Hope this helps, great idea!
Ciao 
I really think that we must add that sort of stuff to the environmental checks. It would allow moodlers to know more (and better) about how their servers will support future Moodle versions without having to discover it suddenly (on upgrade).
To do so, I would propose something like this:
1) Create one new 'CUSTOM_CHECKS' section in the environmental XML files. I will contain on list of 'CUSTOM_CHECK' declarations, each one pointing to one library and one function to be executed. Each check will have the "standard" level (optional/required) and the corresponding FEEDBACK section pointing to the message to be displayed.
2) Create the check functions. All them should share a similar structure, returning true/false depending of how the check has worked and with one unique parameter by reference of class "environment_results" that can be modified by the function itself (like current "bypass" and "restrict" functions. I would create all the functions starting by, say "environment_" to avoid arbitrary function execution and so on.
3) Modify environmentlib to be able to process that new section, calling to the defined functions, processing results and so on. It will inform gracefully if some function isn't found and so on...
4) Once 100% tested, backport the lib, the check functions and the xml file to stable branches.
But yes, +1 to add as many checks as necessary in the environmental stuff. If somebody wants to start to discuss/develop about the basic idea described above it will be great! If nobody starts it, I think I could start doing something in 1-2 weeks from now.
Hope this helps, great idea!
In reply to Eloy Lafuente (stronk7)
Re: How does the pre-upgrade environment check work?
by Dan Poltawski -
Did I hear that the journal module is going to be removed in 1.9 too? (Might be another one to add?)
In reply to Tim Hunt
Re: How does the pre-upgrade environment check work?
Just for reference...
Tim has implemented custom checks in environment code.
Also, there is one nice article for developers about the environmental stuff and how it's supposed to work at:
http://docs.moodle.org/en/Development:Environment_checking
Great job, Tim!
Tim has implemented custom checks in environment code.
Also, there is one nice article for developers about the environmental stuff and how it's supposed to work at:
http://docs.moodle.org/en/Development:Environment_checking
Great job, Tim!
In reply to Eloy Lafuente (stronk7)
Re: How does the pre-upgrade environment check work?
by Tim Hunt -
Eloy,
Thanks for upadating that wiki page.
I agree with the bit about needing _check_ in the funciton name.
I disagree about having a separate file for thises functions. I think it is tidier to put it in the upgrade.php file for the module.
The envirounment check code relates to checks performed at upgrade time (mostly), and so I think it is neater to put it in the same place, and not to have another file cluttering modules for rarely used code.
Thanks for upadating that wiki page.
I agree with the bit about needing _check_ in the funciton name.
I disagree about having a separate file for thises functions. I think it is tidier to put it in the upgrade.php file for the module.
The envirounment check code relates to checks performed at upgrade time (mostly), and so I think it is neater to put it in the same place, and not to have another file cluttering modules for rarely used code.
In reply to Tim Hunt
Re: How does the pre-upgrade environment check work?
Hi,
about the files containing the check functions... I really think that the fact that seemed strange for me was to see your new "/question/upgrade.php" in that dir (where it isn't a standard db/upgrade.php place).
Also, "db/upgrade.php" files have a "rigid" structure (with all those "ifs" performing conditional blocks of code...).
So I see 2 problems by using those upgrade.php files to store environmental function checks:
- Break the "rigid" (but simple and easy readable) structure of the upgrade.php files.
-Potentially (not tested), upgrade code could become executed BEFORE anything else by including those script in the incorrect moment (that sounds really dangerous!!)
So I continue recommending to use a different "environment.php" (or similar) file to store such functions and to have them 100% separated from upgrade.php code.
Ciao
Edited: the risk about upgrade being executed at an incorrect moment isn't possible at all (stroked). But my simple mind continues preferring to have upgrade.php files exclusively containing upgrade code. And to leave environmental functions apart completely, they are different stuff IMO. Not critical-existencial, anyway.
about the files containing the check functions... I really think that the fact that seemed strange for me was to see your new "/question/upgrade.php" in that dir (where it isn't a standard db/upgrade.php place).
Also, "db/upgrade.php" files have a "rigid" structure (with all those "ifs" performing conditional blocks of code...).
So I see 2 problems by using those upgrade.php files to store environmental function checks:
- Break the "rigid" (but simple and easy readable) structure of the upgrade.php files.
-
So I continue recommending to use a different "environment.php" (or similar) file to store such functions and to have them 100% separated from upgrade.php code.
Ciao
Edited: the risk about upgrade being executed at an incorrect moment isn't possible at all (stroked). But my simple mind continues preferring to have upgrade.php files exclusively containing upgrade code. And to leave environmental functions apart completely, they are different stuff IMO. Not critical-existencial, anyway.
In reply to Eloy Lafuente (stronk7)
Re: How does the pre-upgrade environment check work?
by Tim Hunt -
At the moment upgrade.php consists of a single function in the structure you describe.
I still thing having the environment checks as other functions in there is right. It is related code. Files are a good way to group related code, and funcitons within that code a good way to keep the different bits separate.
I created question/upgrade.php because there is no db folder in question. This counts as core code, so it is handled in lib/db. I'm not sure I agree with that. Wouldn't it be easier of question, grade, blog, etc. had thier own db folder, rather than having an absolutely huge amount of stuff in lib/db?
I still thing having the environment checks as other functions in there is right. It is related code. Files are a good way to group related code, and funcitons within that code a good way to keep the different bits separate.
I created question/upgrade.php because there is no db folder in question. This counts as core code, so it is handled in lib/db. I'm not sure I agree with that. Wouldn't it be easier of question, grade, blog, etc. had thier own db folder, rather than having an absolutely huge amount of stuff in lib/db?