1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Implemented XenForo Upgrade Improvement

Discussion in 'Closed Suggestions' started by xf_phantom, Jun 19, 2013.

  1. xf_phantom

    xf_phantom Well-Known Member

    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:cool: 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/ :whistle:
    Last edited: Jun 19, 2013
    DRE and LPH like this.
  2. Chris D

    Chris D XenForo Developer Staff Member

    In a perfect world, add-on developers would ensure their tables are removed upon uninstall.
    DRE, Biker and Brogan like this.
  3. xf_phantom

    xf_phantom Well-Known Member

    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.
    DRE likes this.
  4. xf_phantom

    xf_phantom Well-Known Member

    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.
    DRE likes this.
  5. Mike

    Mike XenForo Developer Staff Member

    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.
    Kevin, Chris D and xf_phantom like this.
  6. xf_phantom

    xf_phantom Well-Known Member

    Great news
    thx for the really great and fast support:)
    DRE likes this.
  7. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    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.
  8. xf_phantom

    xf_phantom Well-Known Member


    I'm sure nobody of us want to lose important data.
    dieketzer likes this.
  9. Chris D

    Chris D XenForo Developer Staff Member

    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:


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


    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:



    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.
    DRE likes this.
  10. Mike

    Mike XenForo Developer Staff Member

    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.
  11. xf_phantom

    xf_phantom Well-Known Member

    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:p
  12. DRE

    DRE Well-Known Member


Share This Page