Updating an installation from 8.5.x towards 9.0.2 and then towards the latest 9.3.1. Unfortunately, getting database issues. Not sure what’s causing this. Anyone able to point me in the right direction here?
An exception occurred while executing ‘ALTER TABLE OAuth2ClientScopes ADD CONSTRAINT FK_497E26F39ECFF1A8 FOREIGN KEY (clientIdentifier) REFERENCES OAuth2Client (identifier) ON DELETE CASCADE’: SQLSTATE[HY000]: General error: 1005 Can’t create table databasename.oauth2clientscopes (errno: 150 “Foreign key constraint is incorrectly formed”)
Previous exceptions
SQLSTATE[HY000]: General error: 1005 Can’t create table databasename.oauth2clientscopes (errno: 150 “Foreign key constraint is incorrectly formed”) (HY000)
SQLSTATE[HY000]: General error: 1005 Can’t create table databasename.oauth2clientscopes (errno: 150 “Foreign key constraint is incorrectly formed”) (HY000)
Its a chicken and egg problem with dependencies in the oAuth tables (you can get similar with express), usually when updating the character set.
If the rest of the update works from the CLI, and you are not using oAuth, you can delete the tables and import them from a fresh 9.x install. Or @jero posted a script to fix from MySQL.
Indeed deleting ALL of the tables and making an export from another install does the trick. Rather strange workaround, shouldn’t this be fixed somehow in the update/upgrade progress or did I do something wrong or…
Such problems during updates with interdependent tables has been a long standing problem. Its nothing new. Disabling foreign key checks in migrations doesn’t always resolve it. Fortunately not many sites use oAuth. With Express, not many sites use complex associations between objects, so again it doesn’t crop up so often.
The problem is probability caused by tables having different collations.
This situation may occur when some tables are created using the collation defined in Concrete, and other tables are created using the mysql dedault collation (foreign keys with columns having different collations often break mysql with the error reported).
To solve the situation of having different collations, the temporary solution is so reset all the tables collations (using the c5:database:charset:set CLI command or the related dashboard page): that way, all the tables will have the same collation.
The definitive solution would be to find when and how some tables are created using the mysql default collation instead of using the collation defined in Concrete.
OK, then running in to the next issue here. This error comes when I move from PHP 7.4 to PHP 8.2:
Doctrine \ Common \ Annotations \ AnnotationException
[Semantical Error] The annotation “@ORM\Entity” in class Concrete\Core\Entity\Site\SiteTree was never imported. Did you maybe forget to add a “use” statement for this annotation?
Any clue to this? I am running other clean installs of 9.3.1 (which is the same as this site), which runs fine. So I’m assuming it’s some generated file that’s gone wrong?
After setting doctrine development mode to true (/dashboard/system/environment/entities), it seems to work… Refreshing did nothing. Kind of weird. Never really used this setting myself. I inherited this website and was tasked to update. Not sure how this breaks the whole ORM though… Any thoughts on this?
Unfortunately, like mentioned above, refreshing does not do the trick here. It’s giving me the same issues. Refreshing says
Proxy classes generated to “/application/config/doctrine/proxies”
In the CLI, but after that, it poops out the same error upon loading the site/dashboard. So at this moment, I’m stuck on having development mode set to on… More thoughts?
