split 'DB changes' into 'DB table modifications' and 'DB table additions'

[rebelde]

Hi,

The checkmark beside "DB changes" has been great. It tells me to not even consider a mod, 'cause nothing is allowed messing with my database.

BUT, I would consider some DB changes if they only added tables, instead of modifying vB's tables. By splitting
'DB changes'
into
'DB table modifications' and
'DB table additions'
I will know better which mods I might consider if really useful.

An additional benefit is that it would encourage mod developers to create new tables instead of altering existing tables. (We might even try to standardize table names so it will be obvious where they came from. Something like this for a table name: 'vborgFacebookConnect')

Thanks for listening and I hope this is a helpful comment!

[Adrian Schneider]

Agree with the split, but not with the table names. That would mess up code quite a bit, and it's just semantically incorrect for me. Use table comments for that.

[rebelde]

Ha! I'll be thrilled if just the first suggestion leads to something.

[Paul M]

Thank you for the suggestion but we wont be splitting db changes into two.

[rebelde]

Haha. That was quick. I did plant the idea in your mind, Paul, and maybe a year from now you will like it.

Cheers

[Carnage]

I think it really depends whats modified.

Many of my mods add tables; I try to design to add not edit where ever possible. However sometimes you just need an extra coloumn somewhere.

Provided that the uninstall code reverts the db to the state it was in before the mod was isntalled; I dont see much of an issue.

[Dean C]

You're being overly paranoid. There's no queries in vB3 that I can remember which depend on the total amount of columns in your table. Therefore adding columns will not do any harm at all.