Implemented XenForo Upgrade Improvement

[xf_phantom]

What about introducing some test suite, before the xenforo upgrade is being called?

e.g. comparing the current database to see if the fields and tables which will be created while the upgrade exist?

If they exist, xenforo should show a error message (and run a optional cleanup) to avoid problems/conflicts (this would cause problems with the different schemas, but the listenersystem can be deactivated )

In a perfect world xenforo could also handle the addon database changes and have a log of the changes, so people would see much faster, where the table/column comes from but that's somethign for another suggestion http://community.invisionpower.com/...-developer-center-database-schema-management/

 

[Chris D]

In a perfect world, add-on developers would ensure their tables are removed upon uninstall.

 

[xf_phantom]

In a perfect world, add-on developers would ensure their tables are removed upon uninstall.

Yes, but once you start the update, you'll not get any notice, that the table exists. That's why users think everythign is ok.

And if it's a table from a feature which isn't used often, you'll probably notice the problem in some weeks and you'll not know, where's the bug coming from.

 

[xf_phantom]

BTW, something similar is already happening while the xenforo installation, where xf runs the check and shows the delete notice, if a original xenforo table exist.

 

[Mike]

Note that we intentionally don't error on duplicates/bad stuff in the upgrade as they can be triggered from things like refreshing. However, that's not perfect because it masks legitimate errors. There would be a way to handle this in general but it's a rather extensive change to say the least.

I have however, added a schema check based on reading from the data writers at the end of the upgrade. This won't check add-ons as listeners don't run in the upgrade system. It simply checks for tables/columns that it expects to be there and will display a message if any are missing. It's not perfect but it's what's doable in the short term.

 

[xf_phantom]

I have however, added a schema check based on reading from the data writers at the end of the upgrade. This won't check add-ons as listeners don't run in the upgrade system. It simply checks for tables/columns that it expects to be there and will display a message if any are missing. It's not perfect but it's what's doable in the short term.

Great news
thx for the really great and fast support

 

[Rigel Kentaurus]

Note that we intentionally don't error on duplicates/bad stuff in the upgrade as they can be triggered from things like refreshing. However, that's not perfect because it masks legitimate errors. There would be a way to handle this in general but it's a rather extensive change to say the least.

I have however, added a schema check based on reading from the data writers at the end of the upgrade. This won't check add-ons as listeners don't run in the upgrade system. It simply checks for tables/columns that it expects to be there and will display a message if any are missing. It's not perfect but it's what's doable in the short term.

If you are introducing a brand new table, I don't see anything wrong with dropping or renaming any similar table that exists. After all, the tables from XF are official by nature and take over any table created by an add-on.

 

[xf_phantom]

PLEASE NO DROPPING

I'm sure nobody of us want to lose important data.

 

[Chris D]

That's all good and well until XenForo release a Gallery add-on or a Blogs add-on where the existing third party solution may or may not use a smart table naming convention.

Again, that is down to the add-on devs, of course, to use a decent naming convention. I discussed this with @Mike earlier and his suggestion was for add-on devs to use a structure such as:

xf_{addon}_{tableId}

So a perfect example would be Forum Watch. In an ideal world, the table would have been called:

xf_bd_forum_watch

The reason even add-on devs should be using the xf_ prefix is it denotes that it is part of the XenForo install. When you do a reinstall of XenForo it wipes out any tables with the xf_ prefix. If they have some other prefix then that won't happen and it could leave dodgy data in there.

So, personally, my Gallery add-on is going to have its tables renamed, thus:

xf_xengallery_media
xf_xengallery_album
xf_xengallery_category

etc.

The main thing is, if we all adhere to a sensible naming convention then you know we all make mistakes. Sometimes we might add a table and forget to amend the uninstall script or in @xfrocks case it was marked as TODO in the code then overlooked. These things happen. But if we ensure we use a good convention like the one @Mike has suggested then most of the time these things won't be an issue.

 

[Mike]

Yeah, I have no intention to irrevocably removing data. For example, with the forum watch add-on, the ideal change would be the add-on renaming the table and then allowing data to be migrated to the official system. If we just dropped the table, when you uninstalled the add-on, you'd kill an official XF table.

Note that as of 1.2 beta 2, it will tell you at the end of the upgrade that the upgrade failed if your forum watch table is in the incorrect format, for example. This is simply designed to prompt people to deal with the problems then and there (by reverting to a backup and resolving the problem there), rather than not realizing that it hasn't necessarily completed successfully and stumbling upon the issues.

I would of course also use this time to note that add-on devs may want to make sure that they use a unique prefix for tables, options, templates, etc to ensure they don't conflict with potential changes in the future. This is especially important when you're extending core features (forums, threads, posts, templates, etc) rather than entirely new systems (galleries, etc) though it's probably a good idea there.

 

[xf_phantom]

I would of course also use this time to note that add-on devs may want to make sure that they use a unique prefix for tables, options, templates, etc to ensure they don't conflict with potential changes in the future. This is especially important when you're extending core features (forums, threads, posts, templates, etc) rather than entirely new systems (galleries, etc) though it's probably a good idea there.

IMO http://xenforo.com/community/forums/official-development-tutorials-and-resources.41/ would be a better place for such notes

they are really important and make addon dev lifes easier

 

[DRE]

That's all good and well until XenForo release a Gallery add-on or a Blogs add-on where the existing third party solution may or may not use a smart table naming convention.

Again, that is down to the add-on devs, of course, to use a decent naming convention. I discussed this with @Mike earlier and his suggestion was for add-on devs to use a structure such as:

xf_{addon}_{tableId}

So a perfect example would be Forum Watch. In an ideal world, the table would have been called:

xf_bd_forum_watch

The reason even add-on devs should be using the xf_ prefix is it denotes that it is part of the XenForo install. When you do a reinstall of XenForo it wipes out any tables with the xf_ prefix. If they have some other prefix then that won't happen and it could leave dodgy data in there.

So, personally, my Gallery add-on is going to have its tables renamed, thus:

xf_xengallery_media
xf_xengallery_album
xf_xengallery_category

etc.

The main thing is, if we all adhere to a sensible naming convention then you know we all make mistakes. Sometimes we might add a table and forget to amend the uninstall script or in @xfrocks case it was marked as TODO in the code then overlooked. These things happen. But if we ensure we use a good convention like the one @Mike has suggested then most of the time these things won't be an issue.

AMEN BROTHA.