clarkwinkelmann Only the posts table should be MyISAM in a normal Flarum install.
That's interesting. In my two installs (one locally and one on shared hosting) both via the standard composer way, all tables are
MyISAM except the two new tables of the
clarkwinkelmann Indeed the Terms migrations expect users to be InnoDB, otherwise MySQL won't be able to create a foreign key (foreign keys are an InnoDB thing I believe).
That's what I have learnt in the last hours. So mixing both storage engines doesn't seem a problem.
And if all my other tables are
MyISAM, that means that foreign key constraints aren't used within the rest of Flarum?
So the foreign keys are somehow attached to the child table? In the case of:
... the foreign keys are attached to the
flagrow_terms_policy_user table and not the
But why did you, Luceos, write:
luceos once you deleted the tables manually, you should also have deleted the foreign key constraints added by the migrations. Now that you didn't the migrations fail.
Are there different ways of deleting a table? if I use the drop table button in phpMyAdmin to drop
flagrow_terms_policy_user, doesn't that delete the foreign key constraints as well? Are there any chances that foreign key constraints survive such a drop?
So coming backt to the InnoDB status error:
LATEST FOREIGN KEY ERROR
2018-05-09 13:05:35 0x7000044e1000 Error in foreign key constraint of table flarum/#sql-11ba_5c:
foreign key (`user_id`) references `users` (`id`) on delete cascade:
Cannot resolve table name close to:
(`id`) on delete cascade
What could that be?
table name close to: (`id`) on delete cascade, shouldn't that be the
users table? And if so, why couldn't the table name be resolved?
I will investigate further...