Describe the issue or problem
I have run the upgrade from our version to 3.5.3 about 10 times now (this is on a test server that has a copy of production data), and I have a cleaned up database dump to start from that fixes the first problems of the upgrade.
After doing some re-configuration of mariadb specifically for the upgrade, I now got an error that is not a DB error (probably?). The current error is
2026-03-04 23:31:23 \[migration: APP\\migration\\upgrade\\v3_5_0\\I9425_SeparateUIAndSubmissionLocales\]
PHP Warning: Undefined array key 0 in /usr/local/ojs/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Collections/Collection.php on line 1894
PHP Fatal error: Uncaught TypeError: PKP\\migration\\upgrade\\v3_5_0\\I9425_SeparateUIAndSubmissionLocales::{closure:PKP\\migration\\upgrade\\v3_5_0\\I9425_SeparateUIAndSubmissionLocales::up():60}(): Return value must be of type array, null returned in /usr/local/ojs/lib/pkp/classes/migration/upgrade/v3_5_0/I9425_SeparateUIAndSubmissionLocales.php:64
Note that before the config changes to mariadb it has been crashing on the metrics table updates ( APP\migration\upgrade\v3_4_0\I6782_MetricsSubmission]) but this time it passed that!
Steps I took leading up to the issue
Running sudo php -d memory_limit=2048M tools/upgrade.php upgrade
What application are you using?
OJS 3.3.0.15 trying to upgrade to 3.5.0.3
Additional information
When running upgrade.php check now, it tells me:
Code version: 3.5.0.3
Database version: 3.3.0.15
Latest version: 3.5.0.3
Database version is older than code version
New question to speed up my drop->insert db->upgrade->crash->drop circle. It seems I could do this step before upgrading:
[migration: APP\migration\upgrade\v3_4_0\I6782_OrphanedMetrics]
How would I do that correctly?
Why would you like to run that upgrade script before starting the actual upgrade? – The scrip will be run as part of the upgrade, and if you run it before, you would also need to remove it from the regular upgrade steps here ojs/dbscripts/xml/upgrade.xml at stable-3_5_0 · pkp/ojs · GitHub, so that it does not try to create the temporary table twice, which would lead to an error.
That script removes metrics for not existing journals and copies the entries for other not existing objects (e.g. submissions) into a temporary table.Then the correct metrics are migrated into new DB tables. At the end, here ojs/dbscripts/xml/upgrade.xml at stable-3_5_0 · pkp/ojs · GitHub, the missing objects metrics are copied back from the temporary table into the metrics_old table, so that journal can investigate and remove manually. If there were no other missing objects metrics, the table metrics will be removed.
So, if you still want to run that script before, you would run it like this: php lib/pkp/tools/migration.php “APP\migration\upgrade\v3_4_0\I6782_OrphanedMetrics” up
And you would need to remove the same line here ojs/dbscripts/xml/upgrade.xml at stable-3_5_0 · pkp/ojs · GitHub.
When you describe it like that I don’t see a need to remove those records, I don’t want to mess with the upgrade.
My thought that made me ask this was that since our dumping and inserting of the backup database when we did our upgrades over and over again, took a very long time, it would help make it faster if I removed the metrics for the old journals that are removed.
Were exactly those metrics leading to the upgrade problems?
If you noted all the problems, maybe to solve them somehow first on the production system before starting the upgrade there…
Hi @bozana, I did get several errors while the upgrade went through the metrics tables, but it helped to improve the mariadb config, so it is not necessary. Our metrics table has 22 million lines. I had to turn off the jobs to be able to display the OJS home page, I found a thread about it.
The only reason to remove metrics of removed journals in advance would now be to make the dump and restore of db faster.
