i think every module that changes stuff in the drupal database should not only have an install script (how to add tables, move the module, configure in admin interface, pref in standard format) but also how to *deinstall* the module. not just remove the module from the directory but also the required mysql statements to remove the tables.

looking at my show tables, there are still a lot of deinstalled tables which should have been removed. now i can do that with some mysql info, but it should be standard in the install document

exapmle 'template' of nstall document
* what does the module do (functionlaity)
* what dos one have to do to install the module
- copy to modules dir
- insert tables
- where what to configure in the admin module
* deinstall
-remove module
-delete tables

my dime

Comments

inerte@inerciasensorial.com.br’s picture

If modules had a function that returned what tables and columns they use, an uninstall module (or a simple function inside system.module) could simple drop them if they are unique to the module being uninstalled and delete the .module file.

A simple hook like:

<code>function rating_db_info() {
  $db_info = array();
  $db_info["rating"] = Array(); // table name
  $db_info["rating"]["nid"] = 1; // Collum name
  $db_info["user"] = Array();
  $db_info["user"]["rating"] = Array();
  return $db_info;
}

function user_db_info() {
  $db_info["user"] = Array();
  $db_info["user"]["uid"] = 1;
  return $db_info;
}

function uninstall_module($module_name) {
  $drop = Array();
  $keep = Array();
  foreach(module_list() as $name) {
    $db_info = module_invoke($module, "db_info");
    foreach ($db_info as $table => $column) {
      // Logic to add tables to drop here. No time to think about it now 
    }
  }

  foreach ($drop as $table => $column) {
    // $sql_query to drop
  }
  unlink($module_name);
}

Just a thought

ax’s picture

this db_info hook! automatic install/update/uninstall, suited for different DBS, ... - many uses. anyone else thinking so?

Stefan Nagtegaal’s picture

Yes, I like this to. I once did a suggestion for this but it didn't made it till this far...

thijs-1’s picture

I like this a lot. It keeps the installation clean and makes it easy to try modules.

Kjartan’s picture

  • The web server usually doesn't have write access to the direectory for security reasons so it can not delete/unlink the file.
  • Deleting database content is permanent and should not be an easy operation. Many users do not back up their data and we will get the blame for any data they loose. Even if the GPL makes us not responsible for it it is bad PR.

I'm more in favor of each module having a hook where it can detail how to uinstall the module, with the necessary SQL commands etc. That way the user has to do some manual work to clean things up.
--
Kjartan

thijs-1’s picture

These problems can be addressed by only allowing the php deinstallation scripts to run from the command line.

Kjartan’s picture

Then you end up with complaints from people who have hosts who don't let them have shell access.

Supporting applications running on unlimited systems and configurations can be hard sometimes Only local images are allowed.

--
Kjartan

breyten’s picture

the database info specified in conf.php may not have the required privileges to delete fields and/or tables, so that's also a problem.

I'm more in favor of Kjartan's idea.