Not exactly sure the best place to post this yet, but I'll post here for now.

For all of you modders out there. This is something that I stressed in earlier versions, but we'll revisit it again. Take a look at this thread.

A modification that was installed altered the database. The problem was, that the field names that were chosen for this modification were ones that we used for 7.1, so it ended up resulting in upgrade problems.

When creating a modification that alters the database, please give the new fields a custom prefix. In this case, instead of ONLINE_AGENT, use something like CUSTOM_ONLINE_AGENT. Just something that is different than the normal field naming convention. That way if future upgrades try to add a new field, there will be no conflicts.

I agree here completely, your mod shouldn't use current variables, you should create new ones as to not break things should a user decide to upgrade; plus it'd be near impossible to find what is needed to uninstall a mod with using pre-existing variables so users would end up with content not needed...

Someone should post this to UBBDev, too...

You should use the best practice of NEVER touching the original products data model.. Create your own tables and field names..

i go one step further and create a new database.. the mysql class isn't married to a particular database, so you can do cross DB joins with no code changes at all to the sql class..

Basically, select queries can look like:



kinda stuff.. the only thing you have to make sure of is that the DB user and DB pass can connect to both DBs (duh) and the query is just as efficient as a intra table join within the same DB..

i stumbled upon it via google about 5yrs ago Linky Poo™

:2c:

I don't, often my mods enhance existing tables, if I would add more tables to the equision, I would need to add extra tables to the query mix, and would loose a little performance.

To each their own.. the performance hit is negligible, imo..

You actually get a HUGE performance increase, depending upon what you are doing..

Example is to split the ubbt_POSTS table up into 2.. 1 ubbt_posts_archive is in another DB (for archived posts) then the normal ubbt_POSTS table stays as is.

Modify ubbt_TOPICS to then have TOPIC_STATUS include a new type 'A' for archive..

then in normal day to day operations, the ubbt_POSTS table is being queried with MUCH less records to retrieve for cfrm and postlist..

only time you would hit up the ubbt_posts_archive table would be for searching or showflat (if archive)..

it's like night/day in performance increase

so i see your point, and believe your example holds for things like extra field in ubbt_USER_PROFILE or whatever.. but there are really quite a few tables where splitting them off would actually increase the speed..

so i guess we agree in some way too