If a modification adds a table to the database...

Dean

in memoriam
If a modification for xf (or any script) adds a table to the database, and xf is updated, would that additional database table be ignored during upgrades and leave the data intact?


Sorry for such a basic question, just curious how these things are normally done.
 
If a modification for xf (or any script) adds a table to the database, and xf is updated, would that additional database table be ignored during upgrades and leave the data intact?


Sorry for such a basic question, just curious how these things are normally done.
Probably. Only the tables that need to be updated are updated, I would imagine. Which by definition means everything else is just ignored. :)
 
Product A makes new tables in database on install

producta_users
producta_posts

User X makes a mod that creates a new table for storing the mod's data

producta_custom

Product A releases an update, which creates another table, and updates an existing one

producta_threads
producta_posts (update query)

Product A has never created producta_custom, so does nothing with it.

After Product A's update, User X realizes there's a core change causing his mod no longer to work and releases an update.

In regards to skins, if you customize a template from a style, and the upgrade system leaves customized templates alone, you'd either have to manually add the difference, or revert the template, and re-add your customization to that template. If the system however is capable of merging where possible, no changes might be needed. Any template it couldn't diff.patch, it could report back to you after leaving it alone.

If the update of product a actually adds new code for a new function and the template is not updated, that function can't work as it can't output the data, or can't execute because of missing parameters, variables, etc.

Seeing how most of the color changes and css2/css3 allows for customizations without editing the layout (the html5 code), I think a lot of styles will not need to bother with an upgrade, redo, etc.
 
Thank you for your answers :) It seems adding a new table to an xf (or other) database, and that tables contents would be completely independent even through upgrades to the software.

Is there a difference between
  1. a stand alone database which has 1 table in it, vs
  2. adding that 1 table to an existing database such as xf?
For instance, does mysql hide all the details of 'what table is added when', the ordering or physical location in the database? Like a computer operating system hides the details of where the files are physically stored on my home computer?

What I mean is, if a database is created by xf (or other), then a new custom table is added, then xf is upgraded and xf adds a new table, does the ordering make any difference?

As you can tell by my questions, I don't program.
 
Is there a difference between
  1. a stand alone database which has 1 table in it, vs
  2. adding that 1 table to an existing database such as xf?

The only difference is that the addon you are using will need to connect to the other DB, so you will also need to provide some sort of config file, and functions to connect to it.

It is much easier to use XF's DB as all the functions you need to update the data will be already available. And if for some reason you need add lots of new tables that are similar to the names used by XF, just use a unique prefix: ie: xn_posts and ma_posts
 
FYI Abomination, I have about 50 custom tables on my phpBB forum install, along with around 100 stored procedures and as you would expect, they have no effect on, nor are they affected by any upgrades.

As others have said though, if you link to the default tables/code in any way, then you may need to manually update your own tables (and functions) after any upgrade to take account of any changes.
 
The light bulb above my head is becoming a bit brighter each day, i.e. some of these things are beginning to make sense.

But...
  • if xf/vb/ipb/phpbb v1.0 creates 100 tables
  • I add 10 custom tables
  • then xf/vb/ipb/phpbb v2.0 creates 50 more tables
  • I add 20 more custom tables
  • then xf/vb/ipb/phpbb v3.0 creates 30 more tables
does that make any difference? Compared to installing xf/vb/ipb/phpbb v3.0 & then my 30 custom tables after that?

Does MySQL take care of the details like a file allocation system on a computer? e.g. the details of where those files are physically located are hidden to me.
 
Tables in a database are just likes files in a directory on your PC/server.

The order in which they are added makes no difference to how they function.

By default they will be listed in alphabetical order in e.g. phpMyAdmin.
 
  • if xf/vb/ipb/phpbb v1.0 creates 100 tables
  • I add 10 custom tables
  • then xf/vb/ipb/phpbb v2.0 creates 50 more tables
  • I add 20 more custom tables
  • then xf/vb/ipb/phpbb v3.0 creates 30 more tables
does that make any difference? Compared to installing xf/vb/ipb/phpbb v3.0 & then my 30 custom tables after that?
No. It absolutely does not make any difference.
... as long as there are no conflicts.

Think of it like adding files (tables) to a single directory (database). User A adds 10 files, User B adds 20 files, User A then adds 10 more files, and so on. Now as long as the filenames (table names) are not same, there won't be any problem; and the files will get added to the directory seamlessly.

Which is why it's usually a good idea to prefix your own table names with some unique character combination, like ab_tablename to prevent the names from conflicting further down the line.
 
Lightbulb.jpg
 
Usually if you want to add any tables to an existing install, you just do them with a prefix, so you if the existing software uses "users" you may use "abom_users" or the mod name. That way people can still clearly understand any standards already used in naming principles, as well as quickly identify the mod the table is associated with.
 
Here's the thing, wordpress makes upgrades an painless, easy process - even though that we're using a skin or theme that isn't a WP standard. Meaning I can just install a skin, and not worry about upgrades later. It just seamlessly upgrades without me worrying about upgrading the skins themselves to be compatible with the said upgrade.

With vbulletin, the administrator has to worry about the skins. In fact, this is what keeps administrators from upgrading in the future - they stay with the old version that has the website's best skin. These administrators risk their security for pleasing users.

Some sites are still VB2, some sites are still VB3, and some are this and that....for the reason I've just described.

I like the upgrade process for vbulletin, the problem isn't the upgrade process, the problem is having to revert skins, AND lose the modifications [that you've made to the skin] in the process, so all your work is down in the toilet.
 
Top Bottom