"dont need to be removed to upgrade" flag
 

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... >.<

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?

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

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

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.

That's a good idea, Wayne.

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)

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

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

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.

The only time any data in the database which is not the original vB database structure will be dropped is if you select to [high]Empty the database[/high], but I think you can only do this via /install/install.php ;)

Satan

I cant ever see much of a reason to append fields to a vb table anyway. In fact, it really annoys me when I see macks that do this when its not needed.

The most common table modified is the user table. Why cant people just use profile fields? Thats essentially what its designed for. That or just include your own table that you can drw information from. Nothing worse than trying to uninstall a mod that has made changes to the underlying vb table structure.

Just my 2 yen (which of course comes to very little at the current exchange rate).

Because it's not very easy. First they have useless names (field6, field7, field8 etc), and secondly there is no way to know what the next one will be on any installation, it could be field6 on one, and field12 on another.

I would rather modify a table "needlessly" when it is the best option. Using a profile field means that you have to find what field it is in, which requires either a setting or a needless datastore row to keep track of. Adding a brand new table means you either add a query needlessly, or you modify queries, which mean needless file edits.

Modifying the user table is much simpler than either of the two alternate methods you mention. Either way, a hack should include an uninstall script.

With an install script it should be easy to fetch the last userfield used and increment that by one??

Or simply have the field be an option in the settings. I do this for GAL and GAB.

An extra table doesnt mean always mean an extra query - all that just depends on your design and (in the end) what youre trying to do.

Although there may be times where its unavoidable, far too many take the lazy way out and simpy append fields to the user table without exploring better and cleaner ways of accomplishing the same thing.

Do tell me how I can create my own table, populate it with EVERY user, then fetch this info as easily as $vbulletin->userinfo WITHOUT any extra queries and WITHOUT file edits.
If you can't do this, then you are full of it :p

Um - Do it with the freaking profile fields thats what they were designed for. Sheesh.

Things would also be made much easier if they would allow hooks into the queries as I mentioned in this post. Then you could accomplish much more (though I am sure people will still rely on appending extra fields on the end of the user table as it was the easier thing to do).

Isnt hacking the Tables about the same thing as hacking the files?

Even worse if you do it wrong.

If you alter any of the existing-default-not-touched vBulletin database structure, yes - If you add to it, no :)

Satan

Only if you want it to be user editable with the profile. Otherwise, the user table is the correct table to modify.

Well, we shall have to agree to disagree. The user profile fields are not just for editable fields - they are for custom user table fields. Otherwise they would just simply append the user table whenever an extra field was required.

Me? I prefer to avoid using any of vbs tables if I can help it which so far has been every time. For those options that would require an optional field, I use the profile fields for the job and it works just fine.

When I hear the purists that shout 'dont mod the file' and happily alter the tables... I have to pleasently chuckle.

Remember though, that adding to the table structure does not invalidate support - Altering existing vBulletin files does ;)

In this respect, their attitude makes more sense :p

Satan

At the very least it will require one or more joins, otherwise you wouldn't be storing the data. Joins can and often are as resource intensive as additional queries, especially if the table is not fully optimized and in sync with the table you are joining it to.

it may not count for the upgrade discussion, but it counts for the database changes discussion

it doesnt? where can I find that info

https://vborg.vbsupport.ru/showthread.php?t=91582

In particular this post by me:
https://vborg.vbsupport.ru/showpost....9&postcount=25

and here on the vBulletin.com forum:
http://www.vbulletin.com/forum/showthread.php?t=145472

However if you alter an existing vBulletin field, or add your own field that happens to conflict with a future vBulletin field you will be told to revert your database first.

well that's not general.

if you change original tables, the supportteam will ask you to revert them, exactly as they do with templates, or when they ask you to upload an original file again..

bahh, i get too slow....

alright, so by "adding to the database" you mean adding tables or adding columns to a vB table?

Yes.