You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered: