"dont need to be removed to upgrade" flag

[Dream]

hey

with the new database/flags thing, would be nice to have a flag that says the difficulty the mod is to install and remove, or if you need to remove it at all when upgrading vbulletin. this is a major concern for me when browsing hacks, as just the thought of upgrading ubb from 5.4 to 5.5 and reinstalling all the hacks... >.<

[kall]

A question: The current layout of the 3.5 forums is supposedly aimed at telling people which hacks change code (which would be replaced on upgrade) but...

How are we supposed to know whether or not a plugin that modifies the database will inadvertently add a column/table that is added in a future version of vBulletin?

[Colin F]

Originally Posted by kall

How are we supposed to know whether or not a plugin that modifies the database will inadvertently add a column/table that is added in a future version of vBulletin?

That's kind of hard to say in advance, isn't it?

[kall]

Well yeah, given that my crystal ball refuses to even tell me the release date of the next beta...

[Wayne Luke]

Originally Posted by kall

How are we supposed to know whether or not a plugin that modifies the database will inadvertently add a column/table that is added in a future version of vBulletin?

A good practice would be to prefix your added fields with a unique identifier.

Say your hack or plugin is called Foxchat for instance and you need to add 3 fields to the user table for it to work... They should be called:

foxchat_field1, foxchat_field2, foxchat_field3.

This would ensure that your field doesn't interfere with future fields. If a standard vBulletin field is implemented to do what you want, it would be your determinatation to migrate to that field and provide an import sequence for it. The same practice can be followed for adding tables.

[amykhar]

That's a good idea, Wayne.

[Dream]

so if I had a foxchat_blah column in my user table it wouldnt affect upgrading? what if the upgrade script drops and rebuilds the user table, it would erase unknown columns (the user table isnt the best example but you know what I mean)

[Paul M]

I doubt a vb upgrade script would ever drop a table, in fact I would be 99.9% certain of it.

[Dream]

"rebuild styles" in "update counters" has an option to drop the template table to renumber templateids from 1

[Paul M]

Yes it does, but it's not an upgrade script, it's built in functionality (and it ought to copy all the fields it finds in the table, but I notice it doesn't). I can't think of any reason an upgrade would need to drop a table, alter it yes, perhaps even clear it, but drop it - no - even if fields are no longer used, they can be just ignored.