Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Murray Roke 453 posts 840 karma points c-trib
    Sep 10, 2014 @ 00:02
    Murray Roke
    1

    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"

    1. I created a property, entered data on a page into it.
    2. I made a backup of the database.
    3. I renamed the property. (so far so good, my data is still there)
    4. I restored the database backup.
    5. I touch the web.config to restart/clear caches.
    6. I pressed import in uSync.
    7. 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.

  • Jeroen Breuer 4860 posts 12127 karma points MVP 3x admin c-trib
    Jul 19, 2016 @ 07:58
    Jeroen Breuer
    0

    Hello,

    I'm having the same issue. Is there a fix for this in uSync for Umbraco 7.3?

    Jeroen

  • Jeroen Breuer 4860 posts 12127 karma points MVP 3x admin c-trib
    Jul 19, 2016 @ 09:07
    Jeroen Breuer
    0

    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.

  • Kevin Jump 1513 posts 9720 karma points MVP 3x c-trib
    Jul 19, 2016 @ 09:19
    Kevin Jump
    1

    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)

    <logger name="Jumoo.uSync">
      <level value="Debug" />
    </logger>
    
  • Jeroen Breuer 4860 posts 12127 karma points MVP 3x admin c-trib
    Jul 19, 2016 @ 09:31
    Jeroen Breuer
    0

    Hmm it looks like the Guids are different somehow. Good know we can save content if the Guid matches. Thanks for you help!

  • Kevin Jump 1513 posts 9720 karma points MVP 3x c-trib
    Jul 19, 2016 @ 09:54
    Kevin Jump
    1

    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

  • Jeroen Breuer 4860 posts 12127 karma points MVP 3x admin c-trib
    Jul 19, 2016 @ 15:04
    Jeroen Breuer
    0

    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

  • Kevin Jump 1513 posts 9720 karma points MVP 3x c-trib
    Jul 19, 2016 @ 18:31
    Kevin Jump
    1

    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.

  • Kevin Jump 1513 posts 9720 karma points MVP 3x c-trib
    Jul 19, 2016 @ 18:44
    Kevin Jump
    1

    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

  • Jeroen Breuer 4860 posts 12127 karma points MVP 3x admin c-trib
    Jul 19, 2016 @ 18:54
    Jeroen Breuer
    0

    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

  • Jeroen Breuer 4860 posts 12127 karma points MVP 3x admin c-trib
    Jul 20, 2016 @ 08:58
    Jeroen Breuer
    0

    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

  • Kevin Jump 1513 posts 9720 karma points MVP 3x c-trib
    Jul 20, 2016 @ 09:29
    Kevin Jump
    1

    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......

  • Kunal 19 posts 116 karma points
    Oct 06, 2017 @ 15:05
    Kunal
    0

    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.

Please Sign in or register to post replies

Write your reply to:

Draft