DictionaryItems import: changing the Guid does not work for items that have children

[ondrejpialek]

Hi Kevin! Big fan.

Having updated to the latest uSync now and running on Umbraco 7.11.1 I get the following exception during import:

The UPDATE statement conflicted with the SAME TABLE REFERENCE constraint "FK_cmsDictionary_cmsDictionary_id". The conflict occurred in database "reskchase-umbraco", table "dbo.cmsDictionary", column 'parent'.

Just before this happens there is the following log entry:

DEBUG Jumoo.uSync.Core.Serializers.DictionarySerializer - Set the Guid of the Dictionary from 62c7da15-1a06-4056-950e-57fbe44b74d6 to 62c7da15-1a06-4056-950e-57fbe44b74d6

NB: There is a bug at the moment - you log this message after assigning the new guid to the entity, so this log line will always show just the new guid twice.

I suspect this has been caused by #186 and potentially in reaction to #183.

The item in question that is having its guid changed has children and I think that is what is causing the FK to throw.

Not sure how to best deal with this, maybe create a temp item with the new guid and assign all children to this, then delete the previous dict item and assign the key and values to the new one? A lot of steps, another approach is making the Umbraco repo handle ID changes properly (by also updating the children, dunno how easy that is).

Cheers!
Ondrej.

[KevinJump]

thanks - yeah its a real pain, I will take a look see if there is anything we can do (suspect your right about the children).

the route cause is probably a bug in Umbraco's dictionary, because as you say it appears you cant set the guid on an item that has children without this happening. but i am quite keen to make sure uSync works for all the versions is does (so v7.6+) so we will have to look at a work around and see if we can predict / sidestep this somehow.

[tomvanenckevort]

Hey both,

I ran into the same issue as Ondrej and I've just submitted a PR for a partial fix for this issue.

The code will now temporarily remove any child dictionary items from the parent, then make the update to the parent item with the updated ID, and finally update the orphaned child items with the new parent ID.
This removes the error of the foreign key conflict.

However, it only fixes that issue and you probably still will run into another foreign key issue with the FK_cmsLanguageText_cmsDictionary_id key on the cmsLanguageText table when updating the ID of a dictionary item.
Because that table has a foreign key to the cmsDictionary table using the dictionary item ID and that key cannot be null, we can't use the same workaround as in my PR for the child items.

From looking through the Umbraco code the only two ways round this that I could see would be:

1. Remove the existing translations from the cmsLanguageText table before updating the dictionary item and then add them back in as new translations with the new dictionary item ID (which is messy IMHO).
2. Get the FK constraint on the cmsLanguageText table updated to include ON UPDATE CASCADE so that when the linked dictionary item ID gets updated, it will automatically update the same IDs in the cmsLanguageText table. But that obviously will need an Umbraco core change.

[KevinJump]

thanks,

To be honest i am starting to forget why we care about the GUID value on dictionary items.

Where we can we do use the GUID because it (usally) makes the updates eaiser if things are renamed - and increasingly things (like content and media) are linked by Udi - but dictionary items are only ever referred to by name ??

So I can see a case for adding this - but i am also considering just reverting back to not caring about dictionary guids - unless someone can give me a good reason not to ???