We have some very old Moodle sites that have been upgraded through lots of versions.
I don't think it's news to anybody that the database schema could eventually differ in reality from what was specified and some checks have now been added.
From bitter experience of finding corrupted data in the database (latest was records existing for forum discussions with no associated posts) it seems that the actual data can become corrupt too.
I would like to discuss adding the structure to actually do a sanity check on the data for each module. I guess this would be done as an additional function in each module. It would be nice to press a button and get a report to confirm (or otherwise) that the database is correct.
Any thoughts?
Howard, the XMLDB editor already offers part of this functionality. Look under # Administration ► Miscellaneous ► XMLDB editor. At the top of the page you have a row of buttons including [Check Indexes] and [Check Bigints], and there is a comment at the end of MDL-15974 about making a [Check defaults]. I think that this is the correct place to add further checks.
And recently I added some consistency checks for the question bank data to the healthcentre, which seems to have a slightly ambiguous status, but can be run by going to admin/health.php.
So I don't think we need a new mechanism, we just need to use existing mechanisms better. I think everyone would be happy if you had time to work on it.
(Well, actually, admin/health.php needs to be completely rewritten so that the strings can be localised, and the tests for a specific module can be inside the module folder, rather than all in health.php.)
And recently I added some consistency checks for the question bank data to the healthcentre, which seems to have a slightly ambiguous status, but can be run by going to admin/health.php.
So I don't think we need a new mechanism, we just need to use existing mechanisms better. I think everyone would be happy if you had time to work on it.
(Well, actually, admin/health.php needs to be completely rewritten so that the strings can be localised, and the tests for a specific module can be inside the module folder, rather than all in health.php.)
Hi Tim,
Actually, I wrote the defaults check (and then Petr made it right - story of my life
) so, yes, I agree. I was just taking the logical step that if the schema can get mucked up then so can the data. I have seen this in the wild.
However, don't you think that this is a step more complicated? You can't infer the correctness of the actual data from the xmldb schema. The modules would actually need code to check their own data - for example, I had forum discussions with no posts which is incorrect and thoroughly breaks backup.
As Moodle sites get more and more ancient then this might increasingly be a problem.
Actually, I wrote the defaults check (and then Petr made it right - story of my life
However, don't you think that this is a step more complicated? You can't infer the correctness of the actual data from the xmldb schema. The modules would actually need code to check their own data - for example, I had forum discussions with no posts which is incorrect and thoroughly breaks backup.
As Moodle sites get more and more ancient then this might increasingly be a problem.
Yes, which is why I mentioned the health centre, and talked about breaking it up to make it modular.
Look in admin/health.php. It is a good idea, but currently the implemetation looks like a prototype. All hard-coded lang strings and strangely named clases. Redoing it proerly would be a good thing.
Look in admin/health.php. It is a good idea, but currently the implemetation looks like a prototype. All hard-coded lang strings and strangely named clases. Redoing it proerly would be a good thing.
Ahhh.. perhaps I should read things properly 
I'll take a look at that - sounds like an interesting project
EDIT:
Ahhh... when you get classes like "problem_00002", you have to wonder. Now what problem could that be?
I'll take a look at that - sounds like an interesting project
EDIT:
Ahhh... when you get classes like "problem_00002", you have to wonder. Now what problem could that be?