|
Joined: Jun 2006
Posts: 9,242 Likes: 1
Former Developer
|
Former Developer
Joined: Jun 2006
Posts: 9,242 Likes: 1 |
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.
|
|
|
|
Joined: Jun 2006
Posts: 16,252 Likes: 112
|
Joined: Jun 2006
Posts: 16,252 Likes: 112 |
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...
|
|
|
|
Joined: Aug 2006
Posts: 1,649 Likes: 1
Pooh-Bah
|
Pooh-Bah
Joined: Aug 2006
Posts: 1,649 Likes: 1 |
Someone should post this to ubbDev, too...
GangsterBB.NET (Ver. 7.6.1.1) PHP Version 5.6.40 / MySQL 5.7.23-23 (was 5.6.41-84.1) / Apache 2.4.54 2007 Content Rulez Contest - Hon Mention UBB.classic 6.7.2 - RIP
|
|
|
|
Joined: Jun 2006
Posts: 457 Likes: 1
Addict
|
Addict
Joined: Jun 2006
Posts: 457 Likes: 1 |
You should use the best practice of NEVER touching the original products data model.. Create your own tables and field names..
Happy Customer !!!
|
|
|
|
Joined: Apr 2007
Posts: 3,940 Likes: 1
Former Developer
|
Former Developer
Joined: Apr 2007
Posts: 3,940 Likes: 1 |
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: SELECT my.FieldName, my.user_id, u.USER_ID
FROM $myDB.TableName my, {$config['TABLE_PREFIX']}USERS u
WHERE my.user_id=u.USER_ID 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™
|
|
|
|
Joined: Aug 2006
Posts: 1,358
Veteran
|
Veteran
Joined: Aug 2006
Posts: 1,358 |
i go one step further and create a new database.. 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.
|
|
|
|
Joined: Apr 2007
Posts: 3,940 Likes: 1
Former Developer
|
Former Developer
Joined: Apr 2007
Posts: 3,940 Likes: 1 |
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 
|
|
|
|
|