As written in the exception section of this page, it's not required to use the full Frankenstein naming, when it comes to database tables of acitivies, i.e. the mod_ part can be drop.
The wiki page however isn't clear about, whether it's still recommended to use mod_ or whether it would have a side effect for older Moodle versions.
Should I add the mod_ prefix to my database tables of my activity plugin?
It is still good practice to use "mod_" as the prefix for your activity module data tables. The exception is there primarily to allow backward compatibility, but new modules should use that convention.
mike
But, with the major caveat, that if your plugin is called 'myplugin', the main table (referenced by the 'instance' field in the course module object) must be called 'myplugin' not 'mod_myplugin', or Moodle will be unable to retrieve important data from it (and, given that, I'd probably encourage the rest of the DB tables for the plugin to skip the 'mod_' part as well, in order to keep them together alphabetically).
Not sure if that made things clearer or added more confusion. :D
Should I now prefix my activity database table with mod_ or not?
The wiki makes it sound likes it's an option, but doesn't has to be strictly followed.
Simple answer - if your plugin is called 'myplugin' and you call the database table 'mod_myplugin' you will get a fatal error (unless this has recently changed in Moodle and I haven't noticed), as Moodle won't be able to find the table to extract the activity instance name + (if relevant) the intro fields. You must call this table 'myplugin' (again, I'm willing to be corrected if there's been a recent change to Moodle that allows for 'mod_myplugin' to work).
For the rest of the tables that your plugin uses internally (e.g. 'myplugin_pages', 'myplugin_grades', 'myplugin_otherstuff'), you are completely free to name them as you want (but, normally, they'd start 'myplugin_').
Okay, thanks for the clarification! Might be useful to update the wiki to not make it sound like it's an optional exception.
Just to be sure my information wasn't out of date, I've checked the core code (now that I'm back in front of a computer where it was easy to do so):
https://github.com/moodle/moodle/blob/master/course/lib.php#L1122
The above line looks for a table called $rawmods[$seq]->modname, which is the activity name, without the 'mod_' prefix - there is no provision for finding a table with the 'mod_' prefix. You may be able to get around this by using the PLUGINNAME_get_coursemodule_info function in your lib.php, to provide the name + intro data, before that line is reached (but I'd still expect other problems).
Interesting... Given that, the documentation should reflect that activity modules should not use "mod_" in their database names. I'm going to make those changes.
mike
For the rest of the tables that your plugin uses internally, you are completely free to name them as you want
Is this also true if we plan to get the plugin through the validation process? Because the plugin validation page says the following:
The names of all database tables should start with the full 'frankenstyle' plugin name. For example block_myblock, or auth_paypal. See exceptions for activity modules below.
Currently our additional tables are called like: myactivity_anothertable
So should we switch to mod_myactivity_anothertable instead?
