Dev/build problem after upgrade

I am facing this issue right now.

  1. I’m not using ZenValidator or Silverware. So I don’t think this is the issue.

  2. I’m still searching for the reference deep in the changelog for model indexes.

  3. I have found this: but am on Windows and am struggling to run sake as ‘bash’ is not recognised as an internal or external command, operable program or batch file.

I installed wamp and a new version of Silverstripe. I imported all my files and tested and thought they were ready for another level of testing.
I exported my databases from the live version and imported them into the test area and ran dev/build?flush=1.

I think there are content issues in the database for Silverstripe version 3 when migrating to version 4. I’m struggling to find how to fix them.

There seems to be others that have had this problem: Upgrade from 3.4.1 to 4.9

If anyone can point to how to update my databases to work effectively with a new version of Silverstripe, I would heartily appreciate it.

Can you share any details of any error messages you’re getting, if you have any additional modules installed, etc.

Regarding running sake from windows, I recommend WSL2 which lets you run linux commands inside a native linux environment which is installed as, from a user point of view, just another application inside your windows installation.
Though it’s worth noting I haven’t tested that out when using a WAMP setup - I was running everything through WSL2 when I tried it, but I think it’s worth a shot.

But other than that, as Tim said, it’s hard to help you without specific information about the actual errors and behaviour you’re seeing.

This was supposed to be in response to another post. dev/build is not updating database after upgrade to SS 4.

It’s just that those two other posts have very similar error messages to mine:

[Emergency] Uncaught SilverStripe\ORM\Connect\DatabaseException: Couldn’t run query: SELECT DISTINCT “File_Live”.“ClassName”, “File_Live”.“LastEdited”, “File_Live”.“Created”, “File_Live”.“Version”, “File_Live”.“CanViewType”, “File_Live”.“CanEditType”, “File_Live”.“Name”, “File_Live”.“Title”, “File_Live”.“ShowInSearch”, “File_Live”.“ParentID”, “File_Live”.“OwnerID”, “File_Live”.“FileHash”, “File_Live”.“FileFilename”, “File_Live”.“FileVariant”, “File_Live”.“ID”, CASE WHEN “File_Live”.“ClassName” IS NOT NULL THEN “File_Live”.“ClassName” ELSE ‘SilverStripe\Assets\File’ END AS “RecordClassName” FROM “File_Live” WHERE (“File_Live”.“ID” = ?) AND (“File_Live”.“ClassName” IN (?)) ORDER BY “File_Live”.“Name” ASC LIMIT 1 Table ‘myx-project.file_live’ doesn’t exist

They are both upgrading from version 3.x to 4.x.

I’m also trying to upgrade similarly. I have a test/play area where I am trying things. Sometimes they work, sometimes they don’t. In this case, the import of the database from the live site did not work.

It seems to be a failed 404? (Guessing as it happens when I click a link)

I did install this undefinedoffset/sortablegridfield (but it seemed OK)?

Attempted the upgrader on it.

Got the cURL error 60 problem working by following the WAMP guidelines from below:

Got to Applying RenameClasses. Fell over on the first file with:
Warning: Undefined array key 314 in phar://C:/wamp64/www/myx-project/upgrade-code.phar/vendor/nikic/php-parser/lib/PhpParser/Lexer.php on line 258
Followed by five more warning on undefined array keys.

Tested to see if the preceding changes had made a difference to the error I am experiencing with suspected failed 404. No change.

Will now see if I can fix what’s wrong with the upgrader.

Checked the upgrader tool: php upgrade-code.phar self-update

[OK] You’re already running the latest stable release.

Checked the PHP version php -v
PHP 8.0.13 (cli) (built: Nov 16 2021 21:58:37) ( ZTS Visual C++ 2019 x64 )
Copyright (c) The PHP Group
Zend Engine v4.0.13, Copyright (c) Zend Technologies

Ahh, this is on windows, isn’t it? I notice there is a case difference between File_Live and myx-project.file_live in that error output. I have a vague memory of people having issues with case sensitive database with windows specifically in the past.

I know this is from the Silverstripe CMS 3 docs, but it does talk about this briefly: so it’s possible that could be of some use… unfortunately I’ve never tried installing Silverstripe CMS on windows directly so I can’t offer any specific advice but it seems likely that case sensitivity is the issue.

The case-sensitiveness issue in MySQL is not specific to Silverstripe: I have met this very same problem on another webapp, and I had to play with the lower_case_table_names setting to let it work.

This is due to the fact that MySQL stores the tables directly as files, and there are case-sensitive and case-insensitive filesystems. Check the MySQL documentation for further details.

1 Like