I have noticed that there is “data loss” when moving from 3.3.0.8 to 3.4.0.4 to the admin profile.
(See attached image)
On the left is our production server (3.3.0.8). On the right is our development/sandbox server we are testing the upgrade. In database update process, some data is eliminated. Please advise.
Of note, the original admin role was “CTL” “Centre for Teaching and Learning” and then updated after moving to 3.0.0.8 to “James” “Holobetz”
Error, I meant updated after moving to 3.3.0.8
Hi @jholobetz ,
This is a data error in your OJS 3.3.0-x (or prior) database, which is resolved in 3.4.0-x by choosing a “preferred” record from among the options. There is more detail on it it here:
opened 01:26PM - 02 Jul 21 UTC
closed 08:43AM - 03 Feb 22 UTC
Bug:1:Low
Housekeeping:1:Todo
**Describe the bug**
The bug described on the forum: https://forum.pkp.sfu.ca/t… /null-values-in-user-settings-safe-to-remove/68272
Old installations may have NULL values in `assoc_type` and `assoc_id` columns in `user_settings` table. This leads to duplicated rows when this data is updated, e.g. through the user profile form:
```
user_id locale setting_name assoc_type assoc_id setting_value setting_type
4 en_US givenName NULL NULL Doe string
4 en_US givenName 0 0 NewDoe string
```
According to the report, this leads to problems in reading user data, the one that I can reproduce appears in Add Reviewer form: searching for a reviewer gives duplicated entries of this particular user in example:

Also, during data retrieval, old setting value, e.g. `Doe` may be displayed instead of `NewDoe`. This one I wasn't able to reproduce
**To Reproduce**
At glance, this problem affects old installs and I'm unable to reproduce it on a clean instance. I can confirm that my old test instance upgraded from 3.0 is affected.
**What application are you using?**
OJS 3.3
**Additional information**
I think to solve the issue the best would be to add an upgrade script that removes duplicates (those with `0` are newer and should remain intact while rows with `NULL` should be removed) or replaces `NULL` values with the default `0`s if the row isn't duplicated.
Associated issue: https://github.com/pkp/pkp-lib/issues/7146
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks for the clarification @asmecher . I was a little confused as to why it was not mirroring production when the data was transferred. It just seemed odd that the most recent update (non-NULL data) to the production (3.3.0.8) database was not preserved in the update to 3.4.0.4. But using the duplicate query Null values in assoc columns in user_settings prevent correct data reading after update · Issue #7167 · pkp/pkp-lib · GitHub @jonasraoni provided helped to verify that no other users are affected in the transfer.
1 Like
asmecher
Closed
February 26, 2024, 4:00pm
6
This topic was automatically closed after 10 days. New replies are no longer allowed.