Skip to first unread message
Francisco Lopes
Apr 18, 2024, 2:59:32 AMApr 18
to AtoM Users
Hello everyone.
We are working on updating the AtoM version from 2.6 to 2.8 and encountered some issues along the way.
Following the "Upgrading" documentation, we reached the step of running "tools:upgrade-sql," and the command was throwing an error related to the "function_object" table. However, we managed to work around the problem by deleting the "function_object_i18n" and "function_object" tables from the database.
After completing the "tools:upgrade-sql" and then "search:populate," everything seemed to be correct until we tried to change anything on the "Site information" tab on "Settings", which resulted in a "500 Internal Server Error" .
The error log was:
WARNING: [pool atom] child 14 said into stderr: "NOTICE: PHP message: Unable to execute INSERT statement. [wrapped: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '126-pt_br' for key 'setting_i18n.PRIMARY']"
We noticed that when restoring the dump to an AtoM of the same version (2.6), the information appears complete in the "Site information" tab. However, when the dump is used in version 2.8, the field "Site base URL (used in MODS and EAD exports)" is not recognized, which is precisely the field ID that is flagged in the error.
We have already tried running "upgrade-sql" both by deleting the "setting_i18n" table and the line flagged as Duplicate entry, but it resulted in some other problem in "search:populate."
One possible solution would be to restore the database without inheriting the configurations so that they can be manually configured after the update, but we are not sure how to do that.
Thanks in advance.
We are working on updating the AtoM version from 2.6 to 2.8 and encountered some issues along the way.
Following the "Upgrading" documentation, we reached the step of running "tools:upgrade-sql," and the command was throwing an error related to the "function_object" table. However, we managed to work around the problem by deleting the "function_object_i18n" and "function_object" tables from the database.
After completing the "tools:upgrade-sql" and then "search:populate," everything seemed to be correct until we tried to change anything on the "Site information" tab on "Settings", which resulted in a "500 Internal Server Error" .
The error log was:
WARNING: [pool atom] child 14 said into stderr: "NOTICE: PHP message: Unable to execute INSERT statement. [wrapped: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '126-pt_br' for key 'setting_i18n.PRIMARY']"
We noticed that when restoring the dump to an AtoM of the same version (2.6), the information appears complete in the "Site information" tab. However, when the dump is used in version 2.8, the field "Site base URL (used in MODS and EAD exports)" is not recognized, which is precisely the field ID that is flagged in the error.
We have already tried running "upgrade-sql" both by deleting the "setting_i18n" table and the line flagged as Duplicate entry, but it resulted in some other problem in "search:populate."
One possible solution would be to restore the database without inheriting the configurations so that they can be manually configured after the update, but we are not sure how to do that.
Thanks in advance.
José Raddaoui
Apr 22, 2024, 12:55:52 PMApr 22
to AtoM Users
Hi Francisco,
It looks like 2.7 introduced some changes related to settings and their source culture:
I'd try to leave a single row in the `setting` and `setting_i18n` tables for the setting with ID 126, and make sure the `setting.source_culture` and the `setting_i18n.culture` columns match in those rows, and that they match the default culture from the application.
Best,
Radda.
Francisco Lopes
Apr 24, 2024, 2:49:27 PMApr 24
to AtoM Users
Thank you for your reply Radda!
It worked! I had to change the default_culture on apps/qubit/config/settings.yml to pt_BR and then match the rows on the tables, keeping only the default culture like you recommended.
Wish you the best,
Francisco Lopes.
It worked! I had to change the default_culture on apps/qubit/config/settings.yml to pt_BR and then match the rows on the tables, keeping only the default culture like you recommended.
Wish you the best,
Francisco Lopes.
Reply all
Reply to author
Forward
0 new messages