We had a problem with relations that were to be updated in the database on the foreign system, but a ‘Duplicate Key’ exception occurred during publishing.
After analysing, we were able to determine that MM relations in the ‘sys_category_record_mm’ table should be updated, although they were different relations via the ‘tablenames’ and ‘fieldname’ columns.
Our starting point was a field that simply saves categories as CSV values, but the problem can presumably also be found in other MM relations.
In the SingleDatabaseRepository class (vendor/in2code/in2publish_core/Classes/Component/Core/Repository/SingleDatabaseRepository. php) there is the method ‘findByPropertyWithJoin’ - here an identifier hash is generated based on the array entries ‘$splitRow[’mmtbl‘][’uid_local‘]’ and ‘$splitRow[’mmtbl‘][’uid_foreign‘]’.
If there are now entries with the same uid_local and uid_foreign but different values in ‘tablenames’ and/or ‘fieldname’, these are given the same identifier (see screenshot).
At this point, the primary key of the table ‘$splitRow[’table‘]’ would have to be analysed in order to create a correct hash across all fields of the key.
Dear in2code team,
We had a problem with relations that were to be updated in the database on the foreign system, but a ‘Duplicate Key’ exception occurred during publishing.
After analysing, we were able to determine that MM relations in the ‘sys_category_record_mm’ table should be updated, although they were different relations via the ‘tablenames’ and ‘fieldname’ columns.
Our starting point was a field that simply saves categories as CSV values, but the problem can presumably also be found in other MM relations.
In the SingleDatabaseRepository class (vendor/in2code/in2publish_core/Classes/Component/Core/Repository/SingleDatabaseRepository. php) there is the method ‘findByPropertyWithJoin’ - here an identifier hash is generated based on the array entries ‘$splitRow[’mmtbl‘][’uid_local‘]’ and ‘$splitRow[’mmtbl‘][’uid_foreign‘]’. If there are now entries with the same uid_local and uid_foreign but different values in ‘tablenames’ and/or ‘fieldname’, these are given the same identifier (see screenshot).
At this point, the primary key of the table ‘$splitRow[’table‘]’ would have to be analysed in order to create a correct hash across all fields of the key.
We have solved it on the clamp at this point:
$mmIdentityProperties = [ $splitRow['mmtbl']['uid_local'], $splitRow['mmtbl']['uid_foreign'], ]; if(isset($splitRow['mmtbl']['tablenames'])) { $mmIdentityProperties[] = $splitRow['mmtbl']['tablenames']; } if(isset($splitRow['mmtbl']['fieldname'])) { $mmIdentityProperties[] = $splitRow['mmtbl']['fieldname']; }
Publisher version: 12.5.3