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

Can't fix Upgrade from 1.5 to 2 Beta Error

Affected version
2.0

MattW

Well-known member
#1
Code:
LogicException: xf_forum_field already exists, but the structure does not match. in src/XF/Db/Schema/Create.php at line 51
XF\Db\Schema\Create->getQuery() in src/XF/Db/Schema/AbstractDdl.php at line 132
XF\Db\Schema\AbstractDdl->apply() in src/XF/Db/SchemaManager.php at line 171
XF\Db\SchemaManager->createTable() in src/XF/Install/Upgrade/2000010-200a.php at line 162
XF\Install\Upgrade\Version2000010->step2() in src/XF/Install/Controller/Upgrade.php at line 152
XF\Install\Controller\Upgrade->actionRun() in src/XF/Mvc/Dispatcher.php at line 232
XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 85
XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 41
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 1771
XF\App->run() in src/XF.php at line 319
XF::runApp() in install/index.php at line 14
1504633057924.png
 

MattW

Well-known member
#2
I think this might actually be related to the Custom Fields addon from Waindigo / ThemeHouse

Code:
library]# grep -iR xf_forum_field *
Waindigo/CustomFields/Extend/Waindigo/Library/DataWriter/Library.php:                                   UPDATE xf_forum_field
Waindigo/CustomFields/Extend/XenForo/DataWriter/Forum.php:                                      UPDATE xf_forum_field
Waindigo/CustomFields/Install/Controller.php:            'xf_forum_field' => array(
Waindigo/CustomFields/Install/Controller.php:            'xf_forum_field' => array(
Waindigo/CustomFields/Install/Controller.php:            'xf_forum_field' => array(
Waindigo/CustomFields/Model/ThreadField.php:                    INNER JOIN xf_forum_field AS ff ON
Waindigo/CustomFields/Model/ThreadField.php:                INNER JOIN xf_forum_field AS ff ON (ff.field_id = field.field_id AND ff.node_id = ?)
Waindigo/CustomFields/Model/ThreadField.php:            FROM xf_forum_field AS ff
Waindigo/CustomFields/Model/ThreadField.php:        $db->delete('xf_forum_field', 'field_id = ' . $db->quote($fieldId));
Waindigo/CustomFields/Model/ThreadField.php:            $db->insert('xf_forum_field',
Waindigo/CustomFields/Model/ThreadField.php:        $db->delete('xf_forum_field', 'node_id = ' . $db->quote($nodeId));
Waindigo/CustomFields/Model/ThreadField.php:            $db->insert('xf_forum_field',
Waindigo/CustomFields/Model/ThreadField.php:                FROM xf_forum_field AS ff
 

Mike

XenForo developer
Staff member
#3
Yes, this would be related to that -- and generally a good example of something we can't resolve. We want a table that already exists but the schema we want doesn't match. There's really no way to safely proceed.

This would have to be resolved before upgrading.

(It's also a good example of why add-ons should use prefixing of tables and columns whenever possible.)
 

Jake B.

Well-known member
#4
I think this might actually be related to the Custom Fields addon from Waindigo / ThemeHouse

Code:
library]# grep -iR xf_forum_field *
Waindigo/CustomFields/Extend/Waindigo/Library/DataWriter/Library.php:                                   UPDATE xf_forum_field
Waindigo/CustomFields/Extend/XenForo/DataWriter/Forum.php:                                      UPDATE xf_forum_field
Waindigo/CustomFields/Install/Controller.php:            'xf_forum_field' => array(
Waindigo/CustomFields/Install/Controller.php:            'xf_forum_field' => array(
Waindigo/CustomFields/Install/Controller.php:            'xf_forum_field' => array(
Waindigo/CustomFields/Model/ThreadField.php:                    INNER JOIN xf_forum_field AS ff ON
Waindigo/CustomFields/Model/ThreadField.php:                INNER JOIN xf_forum_field AS ff ON (ff.field_id = field.field_id AND ff.node_id = ?)
Waindigo/CustomFields/Model/ThreadField.php:            FROM xf_forum_field AS ff
Waindigo/CustomFields/Model/ThreadField.php:        $db->delete('xf_forum_field', 'field_id = ' . $db->quote($fieldId));
Waindigo/CustomFields/Model/ThreadField.php:            $db->insert('xf_forum_field',
Waindigo/CustomFields/Model/ThreadField.php:        $db->delete('xf_forum_field', 'node_id = ' . $db->quote($nodeId));
Waindigo/CustomFields/Model/ThreadField.php:            $db->insert('xf_forum_field',
Waindigo/CustomFields/Model/ThreadField.php:                FROM xf_forum_field AS ff
You can run RENAME TABLE xf_forum_field TO xf_th_forum_field before you upgrade, will try to have a look at the add-on to see what we can do to prevent this when future users upgrade :)
 

BoostN

Active member
#5
(It's also a good example of why add-ons should use prefixing of tables and columns whenever possible.)
So, if we're adding columns, we would use something like "boostn_my_column" correct? I'm assuming the upgrade script checks for "xf_" and acts accordingly.
 

Mike

XenForo developer
Staff member
#6
Note that he mentioned adding a column -- "boostn_my_column" would be fine. As an example, the RM and MG now add columns to the user table like xfrm_resource_count and xfmg_media_count. You want a prefix to avoid conflicts with add-ons or the core (which effectively uses no prefix).

When it comes to tables, you must use the xf_ prefix and then a unique prefix for you/your add-on. To emphasize this, the RM now uses xf_rm_resource as a table; MG uses xf_mg_category. Note that MG 1.x was an example of something not following these best practices which we've now resolved (otherwise, any resolution previously would've been a massive BC break). The xf_ prefix is important in that it lets us know the table is XF related. This means that if you do a reinstall, the table will be removed as expected; more significantly though, it means that our utf8mb4 script knows it can convert the table.