I created a property, entered data on a page into it.
I made a backup of the database.
I renamed the property. (so far so good, my data is still there)
I restored the database backup.
I touch the web.config to restart/clear caches.
I pressed import in uSync.
My data is gone. (I assume because uSync destroyed the old property and created a new one)
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.
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)
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.
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.
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.
We have been using uMigrate for the last 6 years because of this issue, however now with umbraco v8 uMigrate is no longer maintained, and does not support version 8 of umbraco.
So I'm once again looking at uSync...
Have any of these problems all been resolved? What's the general consensus from those who use uSync? especially those on this thread that have had rename type issues?
As long as things have been synced before hand, renaming items, moving them between tabs in v8 will not cause the content associated with them to be deleted.
Moving things between compositions is a little more complicated (as it is with Umbraco). Moving between compositions is in essence a delete and create. So content does go missing - However with uSync.ContentEdition installed the content will be recreated as part of the sync so you wouldn't actually loose any data (although i would always be super carefull moving properties between compositions with or without uSync installed)
Rename Destroys Data
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:
uSync Settings: 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.
Hello,
I'm having the same issue. Is there a fix for this in uSync for Umbraco 7.3?
Jeroen
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.
Hi
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)
Hmm it looks like the Guids are different somehow. Good know we can save content if the Guid matches. Thanks for you help!
yeah,
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.
Kevin
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.
Jeroen
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.
Hi
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 ?)
Kevin
Hello,
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.
Jeroen
Hello,
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 :-).
Jeroen
Cool :)
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.
We have been using uMigrate for the last 6 years because of this issue, however now with umbraco v8 uMigrate is no longer maintained, and does not support version 8 of umbraco.
So I'm once again looking at uSync...
Have any of these problems all been resolved? What's the general consensus from those who use uSync? especially those on this thread that have had rename type issues?
Cheers. Murray.
Hi,
As long as things have been synced before hand, renaming items, moving them between tabs in v8 will not cause the content associated with them to be deleted.
Moving things between compositions is a little more complicated (as it is with Umbraco). Moving between compositions is in essence a delete and create. So content does go missing - However with uSync.ContentEdition installed the content will be recreated as part of the sync so you wouldn't actually loose any data (although i would always be super carefull moving properties between compositions with or without uSync installed)
is working on a reply...