on 2021 Feb 16 2:47 PM
Hi,
We migrated our SAP Commerce instance from y1811 to y2011. After the migration we are getting an exception whenever we try to save some specific customers (any modification from either Backoffice ImpEx, Groovy, etc).
We found the exception is triggered during the process of creating an audit entry for the customer modifications.
See stack trace attached (masteredincommerce is a custom boolean attribute that already existed before upgrading SAP Commerce)
Do you know why this exception might be happening?
Thanks and regards
Request clarification before answering.
Finally we got the reason. We have enabled the audit logic for the entity "User". This entity didn't have any blacklisted properties to audit in 1811, but it does in 1905. For the blacklisted properties to be calculated (DefaultAuditableSaver.findBlacklistedAttributes) all the attributes of the item (before and after the change) are gathered.
There are three different types of attributes from the logic standpoint:
Those three lists of attributes are gathered separately with three different queries, and put in three separate attributes lists. When it comes to save the audit info of the row being modify, those three lists are put in a single list of attributes and the audit logic creates a map from it, with all the attributes of the item and its values.
If an attribute is set as dontOptimize=true in its definition, it means that it will be considered a property and its values will be stored in the separate table (for example, USERPROPS). If you revert the change at some point, the attribute will be subsequently saved in a column of the main table, but the existing info in the properties table is not removed. That means that we will be having data for the attribute in the main table and in the auxiliary table as well.
The error comes when the final list of attributes is created. The affected attribute will be gathered twice, once as a regular attribute and another one as a property. When the audit logic tries to create the map of [attribute + value] in DefaultAuditableSaver.findBlacklistedAttributes it reduces the list to a map without using a merge function to solve the duplicates in the list. Since the resulting list contains the same attribute twice, the logic throws an error trying to create the map.
The solution for us has been basically ensuring that we didn't have any dontOptimize=true attribute in the User entity and truncating the content of USERPROPS table.
In your case, you should check if the affected entity has content in the *PROPS table. If you can find in that table any data related to attributes that are not tagged as dontOptimize=true, you should remove that content because it's not used anymore and is conflicting in the audit.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We are experiencing the same problem in production with a boolean attribute after migrating from 1811 to 1905. We are going to override the class DefaultAuditableSaver to investigate the problem.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
16 | |
5 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.