We have automated our deployment using AppVeyor and thanks to uSync we can deploy all the Umbraco settings (doc type, data type etc.) continuously. For the most part it is awesome, but we are experiencing problems on certain data types.
After stepping through the uSync and Umbraco code, I have tracked down the issue to Umbraco.Core.Persistence.Repositories.DataTypeDefinitionRepository.AddOrUpdatePreValues. If I understand the code correctly, it uses the Ids of the prevalues, to figure out if a prevalue is existing or new. In our situation this breaks. At some point the development database was changed to the previous staging database. At some point the prevalue ids must have come out of sync, and Umbraco/uSync has lost track of what is new and what is old.
Is this a behaviour that is wrong (i.e. is it an uSync bug)? Or should we just clean up or prevalue id mess?
OK, [assuming we are talking about uSync for Umbraco 7.1 here]
it looks like it's a bug - uSync uses the umbraco api but as you've spotted that is then updating the pre-values based on the internal ID and not the alias (key) value.
I think it might be fixable, If i get uSync to read in existing prevalues see if it can do any matching and then pass that back to umbraco to do the update that way we should have the correct IDs - I'll need to have a look - but this is probibliy the biggest bit of the core back office api to change between v6 and 7, so i'll need to get my head around it.
.
The preserve value - was for the older umbraco api; pre-v7 datatypes where even more of a mess (https://github.com/KevinJump/jumps.umbraco.usync/blob/v1.5.8-Umbraco-6/jumps.umbraco.usync/SyncDataType.cs#L170)
the preserve setting was for certain datatypes once you've put the new prevalues in - don't delete any of the old ones. (https://github.com/KevinJump/jumps.umbraco.usync/blob/v1.5.8-Umbraco-6/jumps.umbraco.usync/SyncDataType.cs#L215) but this isn't used in v7 because we are using the new v6.2/v7 API. As above the datatypes api is all new, so i didn't want to remove options until i was sure they wouldn't be needed again.
but i haven't had the chance to test it in all situations yet before it becomes a final version - that bit is a bit further down the list, probably sometime next week.
Awesome. Thanks Kevin. Really appreciated. I don't know if our team will have the time to put the experiential version through it's paces, before you will, but if I will make sure to provide some feedback.
Prevalues are beeing re-created when importing
Hi
We have automated our deployment using AppVeyor and thanks to uSync we can deploy all the Umbraco settings (doc type, data type etc.) continuously. For the most part it is awesome, but we are experiencing problems on certain data types.
After stepping through the uSync and Umbraco code, I have tracked down the issue to Umbraco.Core.Persistence.Repositories.DataTypeDefinitionRepository.AddOrUpdatePreValues. If I understand the code correctly, it uses the Ids of the prevalues, to figure out if a prevalue is existing or new. In our situation this breaks. At some point the development database was changed to the previous staging database. At some point the prevalue ids must have come out of sync, and Umbraco/uSync has lost track of what is new and what is old.
Is this a behaviour that is wrong (i.e. is it an uSync bug)? Or should we just clean up or prevalue id mess?
As an aside, when debugging this I tried to make sense of the preserve uSync configuration. But reading through the source code it appears that that configuration value isn't used? https://github.com/KevinJump/jumps.umbraco.usync/search?utf8=%E2%9C%93&q=preserve
Could you perhaps clarify the preserve configuration option as well?
Bonus info: Umbraco 7.1.6 and uSync 2.4.1.29713
Best regards Emil
OK, [assuming we are talking about uSync for Umbraco 7.1 here]
it looks like it's a bug - uSync uses the umbraco api but as you've spotted that is then updating the pre-values based on the internal ID and not the alias (key) value.
I think it might be fixable, If i get uSync to read in existing prevalues see if it can do any matching and then pass that back to umbraco to do the update that way we should have the correct IDs - I'll need to have a look - but this is probibliy the biggest bit of the core back office api to change between v6 and 7, so i'll need to get my head around it.
.
The preserve value - was for the older umbraco api; pre-v7 datatypes where even more of a mess (https://github.com/KevinJump/jumps.umbraco.usync/blob/v1.5.8-Umbraco-6/jumps.umbraco.usync/SyncDataType.cs#L170)
the preserve setting was for certain datatypes once you've put the new prevalues in - don't delete any of the old ones. (https://github.com/KevinJump/jumps.umbraco.usync/blob/v1.5.8-Umbraco-6/jumps.umbraco.usync/SyncDataType.cs#L215) but this isn't used in v7 because we are using the new v6.2/v7 API. As above the datatypes api is all new, so i didn't want to remove options until i was sure they wouldn't be needed again.
Kevin
Thanks for a quick and detailed reply. I look forward to you getting your head around the issue :-) How far down the priority list is this?
Best regards Emil
fix wise - i've had a little look https://github.com/KevinJump/jumps.umbraco.usync/blob/v2.2-Umbraco-7/jumps.umbraco.usync/SyncDataType.cs#L146
There is an experimental version here https://github.com/KevinJump/jumps.umbraco.usync/tree/v2.2-Umbraco-7/Package/uSync
but i haven't had the chance to test it in all situations yet before it becomes a final version - that bit is a bit further down the list, probably sometime next week.
Awesome. Thanks Kevin. Really appreciated. I don't know if our team will have the time to put the experiential version through it's paces, before you will, but if I will make sure to provide some feedback.
Best regards Emil
is working on a reply...