Details
-
Type:
Sub-task
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Cannot Reproduce
-
Affects Version/s: 2.0
-
Fix Version/s: 2.0
-
Component/s: Database SQL/XMLDB
-
Labels:None
-
Affected Branches:MOODLE_20_STABLE
-
Fixed Branches:MOODLE_20_STABLE
Description
Try to add a new field called questiondecimalpoints int(4) signed not null default -1 with comment "The number of decimal digits to use when displaying question grades. -1 = use decimalpoints, otherwise a separate setting."
I get the error:
Fatal error: Call to a member function getHash() on a non-object in /home/tim/Workspace/moodle_head/admin/xmldb/actions/edit_field_save/edit_field_save.class.php on line 109
This is becuase XMLDB is trying to get the old hash of the field, so it can later see if anything has changed. However, the previous line $table->getField returns NULL, since this is a new field that was not present in the old structure.
Strangely, this code has not changed since it was added to core in August 2006: http://cvs.moodle.org/moodle/admin/xmldb/actions/edit_field_save/edit_field_save.class.php?hideattic=0&revision=1.1&view=markup
Similarly, the method table->getField, although it has moved several times, has not changed at all: http://cvs.moodle.org/moodle/lib/xmldb/classes/XMLDBTable.class.php?hideattic=0&revision=1.22&view=markup, and it has always returned null in this situation.
So, how the hell did it ever used to work. More to the point, why is it that every time I try to use XMLDB, it seems like I have to fix some bugs in it first?
/me goes to edit the XML by hand and swear and curse about the stupid, unnecessary, prev and next attributes.
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
Uhm,
I've been trying to reproduce this in all ways possible:
- Create table, then field, back without saving
- Create table, then field, save (both without modifying the default "changeme" names and modifying them)
- Create and then, while editing the new field, in other tab (same session), look another exiting field specs (edit it, both saving and without saving)
- Force multiple "new field" executions to see if something is being reused incorrectly
And I haven't been able to get any error like the described above. So I'm going to close this as cannot reproduce. Please, if you find some sequence causing it... reopen and comment!
Slightly offtopic: Some days ago, I discovered that Moodle 2.0 sessions weren't being closed properly (due to one error in the destructor)... perhaps that could be causing some malfunction in session data, specially affecting the XMLDB editor when using more that one tab/window. Just a thought, not sure.
Ciao 
- Create table, then field, back without saving
- Create table, then field, save (both without modifying the default "changeme" names and modifying them)
- Create and then, while editing the new field, in other tab (same session), look another exiting field specs (edit it, both saving and without saving)
- Force multiple "new field" executions to see if something is being reused incorrectly
Grrrrrrrrrrrrrrrrrrrrr!
Just hit this again.
Please fix.
Please, please, please!