Related to this, at what point is the updated information sent to the registration agency? We are currently working on a test server to test the upgrade; however, the Crossref configuration in use is the production configuration.
Many thanks,
Gabriela
Hi @dung, thanks. I think your question is a slightly different problem that our current tool doesn’t totally account for. The tool is currently designed to “de-duplicate” entries where a DOI has (on purpose or accidentally) been registered with two different registration agencies.
In your case, if I understand correctly, you have some DOIs that were previously registered with Datacite and now you exclusively register DOIs with Crossref and do not plan on re-registering the older Datacite DOIs with Crossref, correect?
I think we need to assess the tool for handling this to better handle this scenario. I will look into this and keep you updated here.
Thanks for all your help in figuring this out!
Regards,
Erik
PKP Team
Hi @gabriela1, for this question specifically, the updated information will be sent per your configuration (manually or automatically) once you have completed the upgrade and the site is running normally again.
But I think in this case, the current toolset does not accurately handle your situation so we’ll have to make some changes in order to better handle your case.
Regards,
Erik
PKP Team
Hi @ewhanson
Ask me any question you want, I can do testing as well, I would love to contribute in any form. Thank you!
Best,
Dung.
Hi @ewhanson,
Thank you for your assistance.
Yes, you are correct. DOIs were previously registered with Datacite and now we exclusively register DOIs with Crossref and do not plan on re-registering the older Datacite DOIs with Crossref.
Best wishes,
Gabriela
Hi @dung
Following the step where you ended. I followed on and had two duplicates which I removed using:
php tools/resolveAgencyDuplicates.php test
IDs with duplicate DOI registration metadata:
Submissions: [862,884]
Galleys:
Issues:
**** Fix: php tools/resolveAgencyDuplicates.php resolve crossref --force
I now sit with the following error:
[downgrade for “APP\migration\upgrade\v3_4_0\I6782_MetricsIssue” unsupported: Downgrade not supported]
ERROR: Upgrade failed: DB: SQLSTATE[23000]: Integrity constraint violation: 1048 Column ‘submission_id’ cannot be null (SQL: insert into metrics_submission (load_id, context_id, submission_id, representation_id, submission_file_id, file_type, assoc_type, date, metric) select m.load_id, m.context_id, m.submission_id, m.representation_id, m.assoc_id, m.file_type, m.assoc_type, DATE_FORMAT(STR_TO_DATE(m.day, ‘%Y%m%d’), ‘%Y-%m-%d’), m.metric from metrics as m where m.assoc_type = 515 and m.metric_type = ojs::counter)
I am attempting to upgrade from 3.3.0.14 to 3.4.0.8.
Did any anyone experience something like this?
Regards,
Lucian
Hi @ewhanson. Do you have an estimate for when these changes will be available to us? We’ve already announced the upgrade to our journal managers for early August, and some of us have vacation schedules in the meantime. We’d like to assess whether we may need to delay the upgrade.
Best wishes,
Gabriela
Hi @lucian
I am not an OJS supporter but I recommend you to search the forum or follow the prompt of the error and work it out but this will require some technical knowledge. If you want here is my quick search:
Select FROM metrics_submission
WHERE assoc_type = 515
AND metric_type LIKE 'ojs::counter'
AND submission_id IS NULL;
DELETE FROM metrics_submission
WHERE assoc_type = 515
AND metric_type LIKE 'ojs::counter'
AND submission_id IS NULL;
I am not sure that will help though. Best of luck.
Dung.
Hi @lucian and @gabriela1, it sounds like this resolved the DOI issue you mentioned above. If that is the case, once you have this COUNTER issue sorted, you should be okay to proceed with the upgrade. Maybe @bozana might have an idea about the metrics issue.
Thanks,
Erik
PKP Team
Hi @lucian
Could you please execute the following SQL on your 3.3 DB:
SELECT * FROM metrics WHERE submission_id IS NULL and assoc_type = 515
Best,
Bozana
Hello @ewhanson
I am sorry that there was a misunderstanding here - I was trying to help out @lucian based on my theoretical understanding and that was not specifically our solution neither our issue was resolved. @gabriela1 advised me to wait for your instruction. Again, sorry about this confusion.
As our upgrade deadline is tomorrow, August 7th, I’m reaching out to ask if you could kindly assist us.
Best regards,
Dung
Best regards,
Dung.
Hello @ewhanson,
Apologies for the delay in following up. We had scheduled vacation time.
We had an internal discussion earlier, and I can confirm that the issue remains unresolved on our end. We are currently awaiting your assistance to help move things forward.
In the meantime, we have notified our journal managers and editors that the upgrade will need to be delayed until the matter is resolved.
Thank you for your continued support, and we look forward to your guidance.
Best wishes,
Gabriela
Hello @ewhanson ,
We’re still waiting for an update before we can move ahead with the upgrade. Any help or guidance you can share would mean a lot. Thanks so much.
Gabriela
In my experience it is not a good idea to skip releases when upgrading. The best solution is to upgrade each release sequentially until you get to the desired one. Otherwise you are guaranteed to get database errors.
Hi. Yes, but it’s relatively fast once you get going! I did this via FTP using the downloads here:
I wanted to close the loop on this. We have now aliased all DataCite DOIs to Crossref and completed both the reassignment of existing DOIs and the assignment of new DOIs under the updated Crossref configuration.