User X makes a mod that creates a new table for storing the mod's data
Product A releases an update, which creates another table, and updates an existing one
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
a stand alone database which has 1 table in it, vs
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?
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.
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.
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.