"dont need to be removed to upgrade" flag

[Chris M]

Originally Posted by 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.

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

[The Geek]

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

[Paul M]

Originally Posted by The Geek

The most common table modified is the user table. Why cant people just use profile fields?

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.

[Link14716]

Originally Posted by The Geek

That or just include your own table that you can drw information from.

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.

[Colin F]

Originally Posted by Link14716

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

[The Geek]

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.

[Revan]

Originally Posted by The Geek

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.

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

[The Geek]

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?

[Marco van Herwaarden]

Originally Posted by The Geek

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

Even worse if you do it wrong.

[Chris M]

Originally Posted by The Geek

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?

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

Satan