Fixed Uninstalling legacy add-ons will leave orphaned data.

[AndyB]

Affected version

XF2 Beta 3

The following phrase is inaccurate:

Uninstalling legacy add-ons will leave orphaned data.

Please change to:

Uninstalling legacy add-ons may leave orphaned database tables and or schema changes.

 

[AndyB]

Ideally the legacy add-on directory would be read and if there's an uninstall.php file the phrase would indicate:

Uninstalling this legacy add-ons may leave orphaned database tables and or schema changes.

Otherwise if no uninstall.php file is found there would be no phrase at all because the add-on would be completely uninstalled.

 

[Chris D]

Although a change to the phrase might be reasonable (though I wouldn't go as far as to say it's inaccurate, it's just people's understanding of it which may vary), it isn't possible to do it conditionally based on any XF1 code, at all.

We have no way of knowing which files or directories belong to an XF1 add-on, even if the original files still exist. Also bear in mind there's never been any strict convention on the naming of files or where files should be stored, so not only would we not know where to look, we also wouldn't know what to look for.

 

[Snog]

@Chris D while I'm not really concerned with the phrasing, the orphaned data does have me somewhat concerned.

Wouldn't it be possible to maybe request the original XML file if it's available and run the uninstall routine from the legacy XML? Then if the original XML isn't available orphan the data.

 

[Chris D]

As I said in another thread, there's nothing to worry about where orphaned data is concerned. Ok, it's there, it's superfluous, it's not doing anything, but it's also not doing any actual harm.

The schema manager stuff has resiliency built in so that duplicate column and table names aren't going to cause any issues - the old ones will just be renamed (this was mentioned in the Beta 3 announcement thread).

Even if it was possible to run the XF1 code, none of it would be compatible, e.g. how are we going to run XenForo_Application::getDb() or any other combination of XF1 code in an XF2 environment?

 

[Snog]

I understand. Thanks for the explanation.

 

[markku]

@Chris D or anyone with the knowledge:

As an addition, how is this situation resolved (when eventually upgrading from XF1 to XF2)?

Let's say a XF1 forum has, at the time of upgrading from XF1 to XF2, 50 XF1 add-ons, of which 25 will never see upgrades to XF2, 15 have XF2 version available, and 10 will have XF2 version available in the future.

Should the aforementioned 25 XF1 add-ons be uninstalled before initiating the upgrade to XF2, to avoid orphaned data?

Once the upgrade from XF1 to XF2 is complete, can the old XF1 add-ons that have XF2 version available then be updated seamlessly with no orphaned data left after?

What if some of the XF2 add-on versions are "completely new" with a different name but same functionality, I assume - in order to avoid orphaned data - the XF2 add-on version needs to have some kind of process/migration from the XF1 version, when running the add-on upgrade?

And while the 10 XF1 add-ons are waiting for the XF2 versions, they can just be disabled in XF2 for the duration? And if some of them ends up not getting updates after all, then when they are uninstalled, orphaned data may remain?

I guess it's not a huge problem to have orphaned data (?), but it's an annoying thought to have such data left behind, especially for a board that has almost 100 add-ons...

EDIT: Okay, while I was writing Chris explained it's not a problem to have orphaned data.

 

[Chris D]

Should the aforementioned 25 XF1 add-ons be uninstalled before initiating the upgrade to XF2, to avoid orphaned data?

Ideally, yes, for those add-ons you 100% know you don't need or won't be updated.

Once the upgrade from XF1 to XF2 is complete, can the old XF1 add-ons that have XF2 version available then be updated seamlessly with no orphaned data left after?

Yes, that's the main idea by not doing any sort of forced removal beforehand.

What if some of the XF2 add-on versions are "completely new" with a different name but same functionality, I assume - in order to avoid orphaned data - the XF2 add-on version needs to have some kind of process/migration from the XF1 version, when running the add-on upgrade?

That would be down to the developer to handle which should be more than feasible. We've even got a system which allows developers to change the add-on ID.

And while the 10 XF1 add-ons are waiting for the XF2 versions, they can just be disabled in XF2 for the duration? And if some of them ends up not getting updates after all, then when they are uninstalled, orphaned data may remain?

We disable them and mark them as "legacy" automatically.

I guess it's not a huge problem to have orphaned data (?), but it's an annoying thought to have such data left behind, especially for a board that has almost 100 add-ons...

Predominantly the orphaned data will be in their own table, so you will hopefully be able to identify those and drop the tables manually if you feel it is necessary. From a technical point of view, they pose no issue and future conflicts are resolved gracefully.

 

[AndyB]

We have no way of knowing which files or directories belong to an XF1 add-on, even if the original files still exist. Also bear in mind there's never been any strict convention on the naming of files or where files should be stored, so not only would we not know where to look, we also wouldn't know what to look for.

Thank your for explaining.

 

[Jake B.]

As I said in another thread, there's nothing to worry about where orphaned data is concerned. Ok, it's there, it's superfluous, it's not doing anything, but it's also not doing any actual harm.

There is the case of certain field types that can't have a default value (blob, text, and probably at least a couple others) that may have issues when inserting new data and throw an Field 'xyz' doesn't have a default value error

 

[Chris D]

Sure. No solution to this problem is going to be perfect. But, of course, add-on developers should know better(!) and any issues can be resolved if they crop up.

 

[Kirby]

Maybe an idea for a future version:

What about some kind of schema registry so Add-ons could register schema changes with XF in a standardized way?
So if a future XenForo version does break backwards compatibility and there are no updates for certain Add-ons, XF itself could clean-up those fields & tables upon uninstall.

The infrastructure might basically already be there, the Schema Manager could keep track of changes.

 

[Chris D]

As it doesn't pose a particularly significant issue it's likely not worth the effort.

 

[Kirby]

Yeah, it's definitly not a big thing, but still a nice-to-have feature

 

[Snog]

There is the case of certain field types that can't have a default value (blob, text, and probably at least a couple others) that may have issues when inserting new data and throw an Field 'xyz' doesn't have a default value error

Am I missing something here? I've had no problem setting a NULL default value.

XF 1.x:

XXX text NULL
XXX blob NULL

XF 2:

$table->addColumn('XXX', 'BLOB')->nullable();
$table->addColumn('XXX', 'TEXT')->setDefault(NULL);

Granted you can't set them to an actual value, but you can set them to default to NULL.

 

[Chris D]

The issue arises when people don't do that. Which, unfortunately, happens more than we'd like.

Incidentally, you can just set the field to be nullable and it will take care of the default value, e.g.

$table->addColumn('XXX', 'BLOB')->nullable();
$table->addColumn('XXX', 'TEXT')->nullable();

 

[Chris D]

We've changed the phrase slightly for the next release.

 

[AndyB]

Thank you.