Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By _1313 on
After a couple of days of active development my database holds about 80 tables, most of them empty. These are obviously remnants of some modules that i've installed, played with and removed with words of displeasure. Is there some module that can clean this mess? I am dreaming for a tool that will check every table, delete unused ones and report to me is something is broken.
I tried DB_Maintenance module, but it just optimises existing mysql table -- do not want. Help, anyone?
Comments
subscribing...
I'd like to learn more about this as well-- this might sound superstitious or something, but while learning Drupal and testing-then-removing modules over the past year I have the sneaking suspicion that my database tables could use some cleanup as described above. Actually, i have no idea if they really do 'cause I'm not a database guru, but just seems like they're do for a check-up, clean-up, etc.
With drupal 5.x, when
With drupal 5.x, when uninstalling a module, normally the modules database table(s) is being dropped.
Uninstalling is done via the admin/build/modules tab.
On the other hand, use any db manager such as phpmyadmin to maintain your database.
But I wonder if there are
But I wonder if there are some, perhaps misbehaved or improperly/beta coded modules, that might leave "orphaned" tables behind? Again, I might not know what I'm talking about because I'm not all that familiar w/ MySQL, but just seems like that could happen from time to time.
Thanks for phpMyAdmin suggestion; that sounds good *if* I was more confident or really knew what I was doing at the clean-up level... I mean I know how to backup/export my site's database from phpMyAdmin, but that's about all, so it'd be reluctant to start mucking about w/out learning more. And 'course I don't mind learning, but it'd def be nice to have a one-stop "database maintenance/clean up" module if anyone's doing one.
I've rarely seen modules
I've rarely seen modules that provided 'uninstall me' feature.
And yes, i've used PMA yesterday and removed some tables that looked like forgotten trash -- and bang!, my Taxonomy Batch Operations module lost exactly half of its functions.
(well, okay, maybe this "cleanup" of mine have nothing to do with TBO breakdown and i broke it by the other one clumsy move, but i definitely lost any will to conduct experiments on a live DB after this)
...
The "trick" is to find out the unneeded tables. It isn't hard: there's a strong convention to prepend the table names with the module name. So, for example, the tables the Simplenews module generated are prefixed with "simplenews_". If you want to verify that a table prefix indeed denotes a module, try to visit this module's page (
hxxp://drupal.org/project/<put-table-prefix-here>).Whatever, don't lose sleep over this issue. It's not uncommon for a typical installation of Drupal to generate ~80 tables even if no contrib modules are used, and this number increases rapidly if you're using CCK.
I don't think Drupal 5.0 has a GUI for that, but Drupal 6.0 has.
There is now an "Uninstall"
There is now an "Uninstall" tab at the top of the /admin/build/modules page in Drupal 5, where some of the modules appear when you disable them, and let you remove every trace of them (at least that's the theory). But I don't think many modules implement this, so they just don't appear there.
During my "keep everything clean" period I used to remove the tables prefixed with a module's name, its entry in the system table, and all its entries in the variables table as best as I could identify them.
FYI... uninstall doesn't always work as advertised
I have lots of empty tables sitting in my db even after running uninstall.
One of these days will have to make a backup, drop some of these tables, test, repeat... to clean it all up.
Drupal does need improvement in this area.
Same Here
Looks like a little too much faith is being put into module developers to write thorough uninstall scripts. The fact is that the database will accumulate junk.
I think a good-sized chunk is as one respondent said above: tables names usually have the name of the module that used it. There is a second place to scroll through, and that's the `variable` table. Many of the names and values will also contain the name of the module or theme (or at least give some clue as to what it was for).
However, this does require that one is confident with what he is looking at, and what the impact could be. Ultimately, I don't think there could ever bee a reliable "Cleanup Tool" that would be any more effective then the uninstallers that come with their modules. I think the more "reliable" it got, the more risky it would also be against legitimate data.
In my experience, it's a VERY good learning experience to study the modules you use as well as the Drupal API so that you become more comfortable what what's in the database. The database is not some scary, black portal of bits and blobs. A true Drupal expert is one who knows (because he has made the effort to learn) more than just how to dump files in a directory and point n' click :)
Trial and error, but plenty of backups before, and notes after!
Yes.. I have learned some things
One thing I discovered I probably should have already known, because it's probably documented... but I had made the assumption that the proper uninstall sequence was
- disable module
- delete module files
- run uninstall to cleanup database
Of course, there's actually no uninstall to run after you've deleted it. But I had no idea how the whole uninstall thing worked and figured it was in core or something.
Anyway, now know better. What you do is
- disable module
- run uninstall if there is one
- delete module files
Doing it that way allowed me to clean up most of my module test driving mess.
I appreciate the info about the variable table because I'm sure I've got accumulated crud there, and also I have one misbehaving module I could not successfully reinstall because something of it remained somewhere. It's probably in the variables.
You can use the Schema module
You can use the Schema module for discovering the remaining tables from not properly uninstalled modules.
And for the variables table, there mostly is the convention mentioned here before for table names, that they are prefixed with the module name, as far as i noticed (in drupal 6).
Also there are some residuals in the system table, that can be simply identified with the module path.
I just found this simple System Table Cleaner module that does this (if you uninstall the module properly), but why to install an additional module for that, if i can delete them manually after i finish development.
Schema module is also very handy for identifying columns from deleted content (cck) fields.
Is there something else in a common case (besides data in cache tables)?
Wow, thanks for the Schema
Wow, thanks for the Schema module recommendation. Exactly what i was looking for - helped me drop 32 stale DB tables!
Hello, I'm just curious
Hello,
I'm just curious here. Is it something that we often need to use? I mean: do we need to clean-up database regularly?
I don't have any experience in this area.
So, thanks for any clarification.
No
No, you wouldn't normally have to do any cleaning up. It's just a situation that can occurs sometimes when removing modules without properly uninstalling (or the module isn't written well and doesn't clean up after itself). In most cases, just leaving the "mess" there does't hurt anything much I suppose. It just bugs some of us to have tables sitting in the database that have no reason to be there.
Short answer... usually nothing to worry about.
Ok, good to know. Thanks
Ok, good to know.
Thanks
Schema Info
Schema seems to present a great deal of info, all most too much.
I recently upgraded from D6 to D7 and have encountered some significant DB frustrations with modules that haven't upgraded to D7. Through this whole process I've lost my Forum (Core) functionality, consequentially, a module I can't easily uninstall and reinstall.
Since it's difficult for me to comb through all the info I'm getting from Schema I've considered using the Variable Cleanup Module http://drupal.org/project/variable_clean instead of stabbing at PHPMyAdmin
Thoughts?
The variable table is just
The variable table is just one table in the database. I'd be very, very surprised if it achieved what you're looking for considering most of the cruft from moving from D6 to D7 is from migrating to fields from cck and similar (in tables other than the variable table).