Now I am really confused.
For my new junit-question-type I wanted to add a field using update.php.
After several trials which didn't change anything I had deleted the questiontype completely.
From config-table I always delete the sojunit-question entry - I cannot delete the database table of sojunit since it never gets installed.
Now it does not even create the table it used to create because it always says that the table has been created successfully (which is not true because I can't see it in the database) and gives a notice that the question type needs an upgrade.
I have even tried to leave update.php empty putting the new field into install.xml but here I get also the same problem. I think I am overlooking something with the versions in version.php-file!?
How can I get my question type installed properly again (you may take a look at the attachment)?
I just tried it and it seems to work. Here is what I did:
db/install.xml contains the definition of a table question_myqtype with two columns col1 and col2.
There is no upgrade.php at this stage.
db/install.xml contains the definition of a table question_myqtype with three columns col1, col2 and newcol.
upgrade.php contains a single block of code inside the upgrade function, enclosed in an if ($oldversion < 2008080200) check, that adds the column newcol to the table question_myqtype.
In both these cases, install.xml should have been created with the XMLDB editor that you can find under Admin -> Experimental -> XMLDB. XMLDB editor can also generate the block of code in the upgrade file.
So, to put it another way, install.xml should always contain the most up-to-date table definitions and is only used for new installs. upgrade.php contains the code for upgrading from old installs to the latest version, and is only used for upgrading where a previous version of the plugin was installed.
- I deleted the mdl_quesion_sojunit table.
- I deleted the qtype_sojunit_version row from the mdl_config table.
- I copied the code attached to your email into question/type/sojunit.
- I went to the admin screen - the question type was re-installed.
- I checked in the database to see that the table had actually been created - it had.
For each plugin of this type (e.g. myqtype) {
Check that question/type/myqtype/version.php, .../db/upgrade.php and .../db/install.php exist.
if ($CFG->qtype_myqtype_version exists, and is less than the number in version.php) {
Call the upgrade function xmldb_qtype_myqtype_upgrade from
upgrade.php, passing the old version number ($CFG->qtype_myqtype_version)
which says what is currently installed
Update $CFG->qtype_myqtype_version to the latest number from version.php
to record what is currently installed
}
else if ($CFG->qtype_myqtype_version does not exist) {
Create the tables from the definitions in install.xml
Update $CFG->qtype_myqtype_version to the latest number from version.php
to record what is currently installed
}
}
So, to give a specific example of what you need to do as a plugin author. Suppose you make version 2008080100 of your plugin what has one table (say question_myqtype) with two columns, col1 and col2. Then you create version 2008080200 of your plugin which adds a third column, newcol to the table. The for those two releases, the files you need are:
2008080100 release
version.php contains $plugin->version=2008080100db/install.xml contains the definition of a table question_myqtype with two columns col1 and col2.
There is no upgrade.php at this stage.
2008080200 release
version.php contains $plugin->version=2008080200db/install.xml contains the definition of a table question_myqtype with three columns col1, col2 and newcol.
upgrade.php contains a single block of code inside the upgrade function, enclosed in an if ($oldversion < 2008080200) check, that adds the column newcol to the table question_myqtype.
In both these cases, install.xml should have been created with the XMLDB editor that you can find under Admin -> Experimental -> XMLDB. XMLDB editor can also generate the block of code in the upgrade file.
So, to put it another way, install.xml should always contain the most up-to-date table definitions and is only used for new installs. upgrade.php contains the code for upgrading from old installs to the latest version, and is only used for upgrading where a previous version of the plugin was installed.
This post seemed quite useful, so I expanded and preserved it as http://docs.moodle.org/en/Development:Installing_and_upgrading_plugin_database_tables
(Well, I had to do something while waiting for my computer to backup files I want to preserve.)
(Well, I had to do something while waiting for my computer to backup files I want to preserve.)
Hi Tim,
that is fantastic - thank you very very much!
This is a very good description!
By the way - what I needed to do in case I deleted question_sojunit-table from the database and want to install everything back again only with one install.xml-file (including the new fields and no update.php-file) I needed to delete my sojunit-plugin from question/type once and put it back again. This way it worked out now for me.
that is fantastic - thank you very very much!
This is a very good description!
By the way - what I needed to do in case I deleted question_sojunit-table from the database and want to install everything back again only with one install.xml-file (including the new fields and no update.php-file) I needed to delete my sojunit-plugin from question/type once and put it back again. This way it worked out now for me.