Customizing SMF > SMF Coding Discussion

Uninstallation Best Practice: Delete mod's settings on Database removal?

(1/4) > >>

pljones10101833:
Hi,

I'm writing a mod for SMF2.0.2 that has a couple of misc settings, stored in the settings table.  It's also got its own table and uses integration points.  Install is all fine, one <database/> script to get everything done.  Uninstall is split between a <database/> script to drop the table and <code/> to remove the integration points.

What I don't currently do is remove the settings the admin has created: these remain on the SMF settings table forever!

Is that bad?  Should my uninstall <database/> script go in and remove the settings, too?  I'm guessing it would be there and not in the more casual <code/> script?

All views gratefully accepted.

(This work forms part of my dissertation, so you may even get a citation! :D)

Arantor:
You can do that in your <database> but honestly it really does not make a *huge* difference in the scheme of things, and it really will increase your maintenance workload; the last mod I worked on for SMF that was released did this, though there were a *lot* of settings to deal with, and making sure that every one of them was cleaned up was time consuming.

pljones10101833:
Thanks.  Unless anyone's got any counter views, I'll go with the simplest answer :).

Arantor:
It does raise an interesting point, though: whether a future version of SMF could have some method for a package to declare what settings it uses (much like when using $smcFunc['db_create_table'], it logs the tables created) so that it could be automatically cleaned up.

I know from experience that building such a system is not actually that hard to do but in the context of SMF it does raise other questions about implementation.

pljones10101833:
OK, as 172 readers have looked and there's only the two of us talking, I'll mark this as solved.  Thanks Arantor! :)

Navigation

[0] Message Index

[#] Next page