Problems with using the vanilla importer from a phpBB 3.2 forum

calvinb

I'm trying to use the importer to get a (successful, mind) dump of a phpBB 3.2 (upgraded from 3.0, so I could use a 3.0 dump if needed) to importer. It gets to loading table 3, then quits because:

Incorrect integer value: '' for column 'Garden.Settings.Manage' at row 1|Gdn_Database|Query|insert GDN_Permission
                (`RoleID`, `Garden.Email.View`, `Garden.Settings.Manage`, `Garden.Settings.View`, `Garden.SignIn.Allow`,
                `Garden.Users.Add`, `Garden.Users.Edit`, `Garden.Users.Delete`, `Garden.Users.Approve`, `Garden.Activity.Delete`,
                `Garden.Activity.View`, `Garden.Profiles.View`, `Garden.Profiles.Edit`, `Garden.Curation.Manage`, `Garden.Moderation.Manage`, `Garden.PersonalInfo.View`, `Garden.AdvancedNotifications.Allow`,
                `Garden.Community.Manage`, `Conversations.Moderation.Manage`, `Conversations.Conversations.Add`,
                `Vanilla.Approval.Require`, `Vanilla.Comments.Me`) values (:RoleID, :GardenEmailView, :GardenSettingsManage,
                :GardenSettingsView, :GardenSignInAllow, :GardenUsersAdd, :GardenUsersEdit, :GardenUsersDelete, :GardenUsersApprove, :GardenActivityDelete, :GardenActivityView, :GardenProfilesView, :GardenProfilesEdit,
                :GardenCurationManage, :GardenModerationManage, :GardenPersonalInfoView, :GardenAdvancedNotificationsAllow,
                :GardenCommunityManage, :ConversationsModerationManage, :ConversationsConversationsAdd, :VanillaApprovalRequire,
                :VanillaCommentsMe)

If I hack out the problematic roles table (...it's just a tiny int->varchar(255) mapping, idk why it'd be problematic), I get further until it gets to updating counts 8/16. then it becomes

Column 'CountComments' cannot be null

My guess is something in the users table is fucky as that's the only reference to CountComments I can find in the dump, but I'm not sure what. This is a fresh vanilla 2.3.1 install on Ubuntu 14.04, Apache, PHP 7, and MariaDB.

R_J

Incorrect integer value: '' seems to be a good hint. The column expects a number and gets an empty string. Have you tried it with strict mode disabled?

R_J

Incorrect integer value: '' seems to be a good hint. The column expects a number and gets an empty string. Have you tried it with strict mode disabled?

calvinb

As for the first one, I don't see any invalid values at all:

Table: Permission
RoleID:int,_Permissions:varchar(255)
"551","All"
"552","View"
"550","View\,Garden.SignIn.Allow\,Garden.Profiles.Edit\,Garden.Settings.View\,Vanilla.Discussions.Add\,Vanilla.Comments.Add\,Garden.Moderation.Manage"
"547","View"
"559","View\,Garden.SignIn.Allow\,Garden.Profiles.Edit\,Vanilla.Discussions.Add\,Vanilla.Comments.Add"
"553","View\,Garden.SignIn.Allow\,Garden.Profiles.Edit\,Vanilla.Discussions.Add\,Vanilla.Comments.Add"
"548","View\,Garden.SignIn.Allow\,Garden.Profiles.Edit\,Vanilla.Discussions.Add\,Vanilla.Comments.Add"
"549","View\,Garden.SignIn.Allow\,Garden.Profiles.Edit\,Vanilla.Discussions.Add\,Vanilla.Comments.Add"
"555","View\,Garden.SignIn.Allow\,Garden.Profiles.Edit\,Vanilla.Discussions.Add\,Vanilla.Comments.Add"

// Exported Table: Permission (9 rows, 00:00.01)

calvinb

Ok, turning off strict mode on the server got my past loading tables 3/18. It's still going, though.

R_J

"551","All" is of type string,string, while the RoleID must be an integer. That would also fail if strict mode is enabled.

calvinb

The other integers in the tables are all quotes-surrounded, so they should be fine, and did so when I hacked out Permissions.

Thankfully, disabling strict mode managed a successful DB import. Thank you!

R_J

Glad to hear it succeeded in the end. Have fun with Vanilla!

x00

the porter can mess up permissions, in my experience.

Type matters. NULL and "" and 0 could potentially produce very different result and that is critical when permission are concerned.

Always run the normal update procedure.

calvinb

@x00 said:
the porter can mess up permissions, in my experience.

Type matters. NULL and "" and 0 could potentially produce very different result and that is critical when permission are concerned.

Always run the normal update procedure.

1. This is resolved.

2. I don't really think phpBB is a supported drop-in update target.