[OJS2.4.8 to 3.1.2-3] XAMPP, How to Upgrade with upgrade.php

Hi @asmecher,

I partially solved the issue by changing mysql to mysqli in the config.inc.php file. Now the upgrade is launching, however, after a short while it throws an error:

[pre-install]
[load: upgrade.xml]
[version: 3.2.1.1]

[code: Installer Installer::checkPhpVersion]
[data: dbscripts/xml/upgrade/3.1.0_preupdate_review_assignments.xml]

What are your thoughts on that?

Thanks!
e

Hi @erupnik,

I don’t see an error there – that’s part of the normal output of the upgrade process. It looks like it was cut short, though. Did anything appear in the PHP error log?

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher, my bad, I forgot to copy the last line; here’s the entire output:

[pre-install]
[load: upgrade.xml]
[version: 3.2.1.1]

[code: Installer Installer::checkPhpVersion]
[data: dbscripts/xml/upgrade/3.1.0_preupdate_review_assignments.xml]
ERROR: Upgrade failed: DB: Table ‘review_assignments_tmp’ already exists

Hi @erupnik,

The table review_assignments_tmp is created during the upgrade process as a temporary storage area, then deleted when the upgrade completes. If it already exists, it’s because a failed upgrade attempt left it behind.

When an upgrade fails, make sure to totally delete the database, create an empty one, then load it with the contents of a backup you took before running the upgrade.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks @asmecher, indeed it helped to solve the problem! However, something else came up:
[pre-install]
[load: upgrade.xml]
[version: 3.2.1.1]

[code: Installer Installer::checkPhpVersion]
[data: dbscripts/xml/upgrade/3.1.0_preupdate_review_assignments.xml]
[data: dbscripts/xml/upgrade/3.1.0_preupdate_notes.xml (skipped)]
[data: dbscripts/xml/upgrade/3.1.0_preupdate_payments.xml]
[data: dbscripts/xml/upgrade/3.1.1_preupdate_citations.xml]
[data: dbscripts/xml/upgrade/3.1.2_preupdate_user_author_names.xml]

[code: Installer Installer::migrateSubmissionCoverImages]
[data: dbscripts/xml/upgrade/3.2.0_preupdate_email_templates.xml]
[data: dbscripts/xml/upgrade/3.2.0_preupdate_versioning_articleGalleySettings.xml]
ERROR: Upgrade failed: DB: La table ‘submission_galley_settings’ existe déjà

The database was restored to its state before the upgrade trials.

What do you think about that?

Thanks in advance

Hi @erupnik,

This is similar – that table is created during the upgrade, and doesn’t exist in OJS 3.0.2. Are you sure you’re restoring for a backup taken before the first upgrade attempt?

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher, yes I’m restoring the database to a date before any upgrade was done. I repeated the recovery now and I can still see that the “submission_galley_settings” table in the db. Would it be okay to just delete it?

Hi @erupnik,

Does your OJS 3.0.2 database backup have a table called article_galley_settings? It shouldn’t – this should have been removed when you upgraded from OJS 2.x to 3.x. I’d recommend reloading your 3.0.2 database backup, dropping the article_galley_settings table, and trying the upgrade again.

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher, thank you very much, removing the article_galley_settings did help me move forward in the upgrade. Then, it encounters yet another duplicate entry:

[code: Installer Installer::fixAuthorGroup]
[note: docs/release-notes/README-3.1.1]
[data: dbscripts/xml/upgrade/3.1.2_update.xml]
[note: docs/release-notes/README-3.1.2]
[data: dbscripts/xml/upgrade/event_log_oneclickuserid.xml]
[data: dbscripts/xml/upgrade/3.2.0_stylesheet.xml]
[data: dbscripts/xml/upgrade/3.2.0_archiving_settings.xml]
[data: dbscripts/xml/upgrade/3.2.0_update.xml]
[data: dbscripts/xml/upgrade/3.2.0_navigation_menu_items_locale_change.xml]

[code: Installer Installer::migrateSiteLocales]

[code: Installer Installer::migrateSidebarBlocks]

[code: Installer Installer::migrateSiteStylesheet]

[code: Installer Installer::migrateMetadataSettings]

[code: Installer Installer::createLicenseTerms]

[code: Installer Installer::installEmailTemplate]

[code: Installer Installer::changeUserRolesAndStageAssignmentsForStagePermitSubmissionEdit]
[data: dbscripts/xml/upgrade/3.2.0_versioning.xml]
ERROR: Upgrade failed: DB: Duplicate entry ‘submissionSubject-1048588-90’ for key ‘controlled_vocab_symbolic’

Thanks again for your time!
e

Hi @erupnik,

In your OJS 2.x database, are there any entries in the controlled_vocabs table with symbolic = 'submissionSubject'?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,
Yes, there are many of entries with this symbolic.
By the way, I’m upgrading from OJS 3.0.2.0.

Looking forward to hearing from you,
e

However, I don’t find any entry with id 1048588-90. All entry IDs start with 1048585-

Hi all,
Has anyone encountered a similar issue or has some idea to fix it? @asmecher maybe?
Thanks!

Hi @erupnik,

I wonder if you have submissionSubject entries for nonexistent articles. Can you try the following query on your OJS 3.0.2 database?

SELECT COUNT(*) FROM controlled_vocabs cv LEFT JOIN submissions s ON (s.submission_id = cv.assoc_id) WHERE cv.assoc_type = 1048585 AND s.submission_id IS NULL;

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher, thank you for the answer. I just tried the query, there is no entries complying with those conditions (see the file attached). ;|phmyadmin_requet

Hello @asmecher, do you there is a workaround similar to the one suggested here: Upgrade error: Duplicate entry 'xxx-yyy' for key 'citations_publication_seq' · Issue #5626 · pkp/pkp-lib · GitHub

thanks,
e

Hi @erupnik,

No, that resolution would help if you were dealing with the citations table, but this issue seems related to the controlled_vocabs table.

Would you be willing to provide me with a database dump? If so, send me a private message with information on how to access it.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher , yes of course, I sent you a link to access the dump in a private message. Sorry for nagging you about this again.

Hi @erupnik,

Thanks for your patience – we’re a small team with a lot of competing priorities, and working with 3rd-party data is time-consuming! I’ve identified the problem and filed an issue here:

There are instructions for patching at the bottom of the page.

I encountered one further problem with your data (to do with the citations table). There’s a work-around documented here but in brief, execute the SQL DELETE FROM citations; before running the upgrade script, perform the upgrade, then run php lib/pkp/tools/parseCitations.php afterwards to re-generate the data.

Regards,
Alec Smecher
Public Knowledge Project Team

Dear @asmecher,
It worked beautifully! Thank you so much for your help, I appreciate your time & energy.
All the best,
er

1 Like