Jeremy
in memoriam 1991-2020
Hey,
The method for handling install / uninstall on XenForo is amazing and powerful. However, I feel that handling 'upgrades' are kind of lacking... I was talking to Jaxel who is using IF NOT EXISTS and other such mySQL queries to insert / create tables. However, I propose a new setting for add-ons: Upgrade Code. Where this code is only run when you upgrade via the Add ons -> Add on -> Controls -> Upgrade Addon and is passed the version number of the current add on (that you're over writing) and you place it on developers to handle upgrading. Something like this:
This will be powerful, and more than just 'cascading' in a sense. The second if() is something I see as extremely useful. So for version ID 2, I add something, but in version ID 5, I decide to move it. If I upgrade from version ID 3, I want to remove the table, but if I'm upgrading from version ID 6, its not there any more, so we don't want to do it.
It'll help create cleaner / more organized SQL and stuff for install() and uninstall(), separating upgrade functionality.
The method for handling install / uninstall on XenForo is amazing and powerful. However, I feel that handling 'upgrades' are kind of lacking... I was talking to Jaxel who is using IF NOT EXISTS and other such mySQL queries to insert / create tables. However, I propose a new setting for add-ons: Upgrade Code. Where this code is only run when you upgrade via the Add ons -> Add on -> Controls -> Upgrade Addon and is passed the version number of the current add on (that you're over writing) and you place it on developers to handle upgrading. Something like this:
PHP:
class addOn
{
public static function upgrade($version)
{
if($version < 2)
{
// This stuff was added in version id 2
}
if($version >= 2 && $version < 5)
{
// This stuff was added in version id 2, but removed in version id 5, so we don't want to try to remove it... etc...
}
}
}
This will be powerful, and more than just 'cascading' in a sense. The second if() is something I see as extremely useful. So for version ID 2, I add something, but in version ID 5, I decide to move it. If I upgrade from version ID 3, I want to remove the table, but if I'm upgrading from version ID 6, its not there any more, so we don't want to do it.
It'll help create cleaner / more organized SQL and stuff for install() and uninstall(), separating upgrade functionality.
Upvote
3