We have several groups of developers working on a site. Each of these groups uses their own dev database. We check the usync files into source control and deploy to the dev sites using TeamCity. The usyncSettings.config files on the dev sites are all set to
read=false
write=false
attach=false
We will periodically log in to those dev servers and flip read=true, recycle the app pool, and then set read=false when we are done sucking in the usync changes. Today, I found out that usync will create new doc types and new properties, but I can't get it to update the property type of an existing property. I have tried this on a couple of different properties. The first doc type I tried it on has been around for a while. I thought that maybe something had happened to it in its past that was confusing usync. Maybe it had been renamed or moved around? The second doc type was read in today, so I know that usync isn't having any other troubles with it.
Is usync capable of updating property types of existing properties? If so, was it capable of this in prior versions? We have a lot of sites using usync at this point, and have not noticed this problem yet.
This fellow seems to be having the same problem. You mentioned that it was a problem with the umbraco API in version 7.1.4. Has anything changed that would allow us to fix that issue?
yeah, this is something I haven't been back to check, in v7.1.4 there was an issue when trying to change the type. more precisely the underling database type of an element when you changed the property type.
I'm not 100% i'm not fighting a loosing battle with is one.
I've added the code while testing and If you change a PropertyType from a TextString to a Data Time Picker, then the change works (you loose any content that was in the picker) and you can use the datatime picker in the content.
If you change from a DateTime picker to a Textstring, then when you try to load the content umbraco fails.
This is actually what happens if you change the propertytype from Date Time to Textstring via the interface - so could be considered a bug in umbraco. (need to confirm it isn't).
So some change types work, (text -> datatime) but others fail (datetime->text)
changing propertyeditor to something that has the same underling type (textstring -> text multiple) works, and keeps your data.
this is umbraco behavior (upto 7.1.9 as far as i can tell). and not uSync.
I am 50/50 as to wether or not i should turn this code on in uSync as it can be quite a pain if it happens.
but if you want to test it the latest jumps.umbraco.usync.dll in github will have a go at chaning values for you
Usync does not update property type of existing property
I have an umbraco 7.1.8 site using usync 2.4.0.
We have several groups of developers working on a site. Each of these groups uses their own dev database. We check the usync files into source control and deploy to the dev sites using TeamCity. The usyncSettings.config files on the dev sites are all set to
read=false write=false attach=false
We will periodically log in to those dev servers and flip read=true, recycle the app pool, and then set read=false when we are done sucking in the usync changes. Today, I found out that usync will create new doc types and new properties, but I can't get it to update the property type of an existing property. I have tried this on a couple of different properties. The first doc type I tried it on has been around for a while. I thought that maybe something had happened to it in its past that was confusing usync. Maybe it had been renamed or moved around? The second doc type was read in today, so I know that usync isn't having any other troubles with it.
Is usync capable of updating property types of existing properties? If so, was it capable of this in prior versions? We have a lot of sites using usync at this point, and have not noticed this problem yet.
This fellow seems to be having the same problem. You mentioned that it was a problem with the umbraco API in version 7.1.4. Has anything changed that would allow us to fix that issue?
Thanks!
yeah, this is something I haven't been back to check, in v7.1.4 there was an issue when trying to change the type. more precisely the underling database type of an element when you changed the property type.
The code is all there commented out,
https://github.com/KevinJump/jumps.umbraco.usync/blob/v2.2-Umbraco-7/jumps.umbraco.usync/Extensions/IContentTypeExtensions.cs#L233
i Just need some time to test it against later versions and confirm if it works or not.
I'm not 100% i'm not fighting a loosing battle with is one.
I've added the code while testing and If you change a PropertyType from a TextString to a Data Time Picker, then the change works (you loose any content that was in the picker) and you can use the datatime picker in the content.
If you change from a DateTime picker to a Textstring, then when you try to load the content umbraco fails.
Server error: Contact administrator, see log for full details.
Failed to retrieve data for content id 1052
and you also can't then delete that node
This is actually what happens if you change the propertytype from Date Time to Textstring via the interface - so could be considered a bug in umbraco. (need to confirm it isn't).
So some change types work, (text -> datatime) but others fail (datetime->text)
changing propertyeditor to something that has the same underling type (textstring -> text multiple) works, and keeps your data.
this is umbraco behavior (upto 7.1.9 as far as i can tell). and not uSync.
I am 50/50 as to wether or not i should turn this code on in uSync as it can be quite a pain if it happens.
but if you want to test it the latest jumps.umbraco.usync.dll in github will have a go at chaning values for you
https://github.com/KevinJump/jumps.umbraco.usync/tree/v2.2-Umbraco-7/Package/uSync
is working on a reply...