cancel
Showing results for 
Search instead for 
Did you mean: 

Duplicate key error when saving a customer in SAP Commerce 2011

former_member634398
Discoverer
0 Kudos
1,365

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

stack-trace-customer-save.txt

Accepted Solutions (0)

Answers (2)

Answers (2)

carlosexojo
Discoverer
0 Kudos

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:

  • Regular attributes: the ones stored in the item table as regular columns.
  • Localized attributes: those stored in the localization table of the type (for example, USERS => USERSLP)
  • Properties: those stored separately in an auxiliary table for performance reasons (for example, USERS => USERPROPS)

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.

carlosexojo
Discoverer
0 Kudos

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.