Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
Using just the back office, I find re-naming destroys and re-creates properties when moving to a new DB thus losing my data.
Here's how I tested:
read="false" write="false" attach="true" folder="~/uSync/"
archive="~/uSync.Archive" versions="true" maxVersions="0" preserve="true"
watchFolder="false" dontThrowErrors="false" quickUpdate="false"
Is there a way round this problem if I need to rename something?
I assume I need to rename it on each machine before deploying the updated def.config files. Is the recommended method? NB: We have an automated deployment environment using TeamCity and OctopusDeploy, so we would prefer an automated solution.
I can set DeletePropertyValues="false" but that doesn't help get the data in the correctly named fields.
I'm having the same issue. Is there a fix for this in uSync for Umbraco 7.3?
Guess for now a workaround is to rename them back to the original name. We've lost content on our QA, but we haven't deployed yet to UAT. So if they have their original name again we should be able to keep the content.
It should handle this as long as the properties across the versions match in guid (which is something usync should do).
usync will attempt to match properties by Guid first, if it does this then it will rename properties in place so should keep the data.
but if for some reason it doesn't find the property via its guid, then it will lookup the property by name, and if it's a rename it won't find it so will create a new one and delete the old one.
if you turn on debug logging for usync (see below) then you should see the lookups, and the keys getting set.
(the code here: this is the v7_4 branch but it should be in usync v3.0.4 for v7.3)
(to turn on logging just Add this to log4net.config)
<level value="Debug" />
Hmm it looks like the Guids are different somehow. Good know we can save content if the Guid matches. Thanks for you help!
I will have a look at that and double check it, a sync via uSync should make the guids match, but I am not 100% sure that works on 7.3 there are certainly areas (like members) where the guids are all zeros.
Hmm I tried my workaround and renamed the properties back to their original alias. The content is still lost. Is this because I still updated the names instead of also the alias? Should it be exactly the same as before? Any safe way to keep the content? Now the content is gone on qa and uat. I can't move it to production like this.
I think when you delete a property, umbraco deletes and content associated with the property, so the content has probably gone, because the rename was a delete and then a create.
As previously stated, usync shouldn't do this if the guids are in sync but it can happen. In previous versions there was a 'don't do the delete' flag in the config, but it caused as many problems as it solved, as you could end up with properties on the target that didn't exist anywhere else.
I am going to have a look at the logic inside usync to see if there are other ways to work out if the orphaned property is a result of a rename (it can be really difficult because lots of other things can change).
one possible way to always keep the content is to sync it with uSync.ContentEdition but that will only really work if the content on the target is the same as the source.
Just so i can do some like for like testing what version 7.3 umbraco are you running on your sites (assuming you are using usync 3.0.4 ?)
Thanks for your help. The version is Umbraco 7.3.8. We're using uSync 3.0.3 with uSync.Core 5.1.0.
The strange thing is that I renamed a property. Moved it to qa. Saw it was deleted. Renamed it back to the original and than pushed to uat. The changed alias was never pushed to uat. Only the changed name, but the content was still deleted.
I made sure that all properties had the exact same values as before the renaming (alias + name + tab). I restored the UAT database before we had the content lost. I ran uSync again and this time the content wasn't lost :-).
Thinking about it, i suspect the riskiest element is the property GUIDs not being in sync between the source and target sites, if you haven't done a sync of an existing property before a rename then it's likely usync won't find it and do the create/delete rename instead.
I am wondering if there needs to be some form of sync flag, to say check if things are synced before renames or deletes. - not sure how this might work, I don't want to store extra info in exports if i can help it, and tracking property renames/deletes directly adds a lot of overhead and brings its own sync problems.
anyway, glad it worked, and i am thinking......
I think we are still having this issue. Not only renaming, even moving a property to a different tab causes the data for that property to be deleted on syncing.
(Tried both automatic as well manual import with same results).
Also another unrelated thing I noticed was that the report showed 15 changes before importing, but after running the import it showed 31 changes were made.
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted