|
[
Permalink
| « Hide
]
Tim Hunt added a comment - 20/Nov/08 07:29 PM
Thanks Colin, but can you attach a patch? Thanks.
Sure,
Not quite sure how to create patches (kinda rushed so I'll figure that out later). So for now I'll paste the methods as they now stand. Our bugzilla number for this bug is 6750 /*
$status = true; // ou-specific begins export standard moodle backups bug #6750
if(function_exists('ou_backup_writeRecordsToFile')){
$status = ou_backup_writeRecordsToFile($bf, $records, 6, 'MATCH_DEFINITIONS', 'MATCH_DEFINITION');
} $records = get_records('question_match_sub', 'question', $question, 'id ASC'); /*
$status = true; //Get the matchs array //We have to build the subquestions field (a list of match_sub id) //Iterate over matchs //We'll need this later!! //Now, build the question_match_SUB record structure //The structure is equal to the db, so insert the question_match_sub //Do some output if ($newid) {
//We have the newid, update backup_ids
backup_putid($preferences->backup_unique_code,$table,$oldid,
$newid);
} else {
$status = false;
} return $status; In Eclipse, Window -> Show view -> Other ... -> Team -> Synchronise (If you don't already have it open.)
The select some files in that view, and do create patch from the context menu. For other options see http://docs.moodle.org/en/Development:How_to_create_a_patch I don't really like your fix. To start with you don't really need MATCH_DEFINITIONS and MATCH_DEFINITION, because there is only one MATCH_DEFINITION for each matching questions. Also, MATCH_DEFINITION is long, and unrelated to any other naming convention in the quiz. MATCH_OPTIONS is probably the least bad, since MATCH is taken. (MATCH would be consistent with how every other question type that has data like this backs it up.) MATCH_OPTIONS is good because elsewhere in the code, when this data is loaded into memory, it gets stored in $question->options.
Also, code like ou_backup_writeRecordsToFile/ou_restore_getRecordsFromFileToDB is nice in abstract, and probably backup and restore should have had something like that from the start, but unfortunately, in core at the moment, consistency is more important. So I will probably reimplement your fix in the next couple of days, but at least it is very clear what I have to do. Sorry or thanks, whichever you feel is more appropriate. No problems. Match options sounds better. I just didn't know what convention to follow and I didn't have much time. The method abstraction is something I'm working on when I get time. I'm keeping it separate from core code as you can see because it's new. I didn't expect core to want it but didn't have time to translate.
Atleast you could make sense of it. col |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||