Importing content type won't update properties about chauffeur

[KevinJump]

yes the design of the package engine is that it won't do destructive updates so only adds stuff it doesn't find :(

also the packging engine is sort of built assuming anything you want to refreence will be in your package so internal IDs and the like are also not mapped.

in umbraco 7.6/7 this is less of an issue when you are using the UID based property editors (that store Guids everywhere) but you still might have legacy ones or need to map things.

uSync does mapping on its imports so for example if you have a Multi Node Content picker with a root node set, then the datatype will have internal IDs in it, and you will need them to be mapped, uSync on export turns the IDs into paths, and on import walks the paths to find the target ids.

For content-types this happens for templates, compositions, allowed types and datatypes, some of these can be looked up via the aliases, but it gets complicated if they are also being updated at the same time (hence all the guids being stored everywhere), as their names might be different than what you expect

the 'simple' way (and i would say this) is to use the uSync serializers - in the uSync.Core project, these don't have any dependencies on umbraco running and can serialise XELements in and out of umbraco, all in memory.

the uSync.Chauffer code is a bit clunky but is doing this with uSyncBackOffice assemblies - mainly because it means you can just do whole uSync folder imports in one command, there it does

uSync content-type import <folder with content-types in>

but there is no real reason while that couldn't be a single file passed to the serialiser and then imported into umbraco. (the usync chauffer package is using usync.backoffice mainly for speed as it also checks for changes before importing and only imports things when they have changed, this is drastically faster than just updating everything and is critical for usync not killing people's websites)

[aaronpowell]

Thanks for the insight @KevinJump, it's a pretty frustrating thing to deal with. I get the pain of the numerical ID's, for the most part that doesn't seem to be a problem, but the fact that it bails out on property updates is really... sucky.

Guess I'll write my own implementation like you guys did for uSync, I think I'll just wrap the IPackagingService given that I already override it to handle macros.

I've just created a test in 7be0503 that will allow me to test as I go along.

[KevinJump]

yeah, i starter just wrapping the packaging service, but in the end all the little things made it easier to implement it compleatly.

the packaging stuff has improved over time - so it might not be as bad now - but the big stinger for usync was the order of things and the extra keys (so extra keeping guids so you can track things) - the order properties come back from the packaging service will be dependent on the database,

so you can't do a direct comparison between something you have on disk and the one umbraco creates, and it doesn't do put the guid keys in everywhere (e.g structure / compositions) so you end up doing the package export and then going over most things yourself - and re-doing lookups to get the extra information - at that point the code was to messy, and performance was a bit poor :( so we moved to just doing everything we needed in usync.

[aaronpowell]

I've gone about creating my own wrapper, so far it's working with my scenarios 😛

[aaronpowell]

Released as part of 0.12.0