Hey all, you most probably all have had to deal with this situation at some point when working with Content Cloud, basically an editor cant publish changes as the property type is out of synch in database compared to what it is in code.
When coming across this issue we normally have to start with a fresh database or fiddle with the existing database inside the following tables [tblPropertyDefinitionType] and [tblPropertyDefinition]
Firstly I would like to understand why when deploying from one environment to another this issue occurs, and secondly is their a better way to resolve this issue.
I have looked at the assembley version numbers and am incrementing this so this is not the issue.
Minesh, did you try renaming the property then redeploying to both environments?
This commonly happens when you've decided you want to change the type of a property but once you've initalized the website, its too late to change it since its been generated as a new definition in the tables you've mentioned. But im sure you know this already!
Could a member of your team changed the type perhaps after it was already deployed to preprod?
Its quite a big squad and pre-prod was quite stale prior to us promoting the latest codebase. Renaming properties or Deleting Properties and than re-creating does do the trick just very frustrating.
If their are no easier more efficient ways I'll stick to doing this, problem I have its quite a few properties causing me issues :(
The most painful scenario is when it happens in Production, because then you need to worry about how to keep the data thats already been done by the real world editors!! There are some techniques to help with that.
If you really don't want to rename the property AND you don't care about the existing data against that property then you could create a migration step and delete the property and recreate it again.
I would personally just rename and be done with it.
Doing some more digging I dont believe the ModelTypeSync is running correctly.
Utilising the ContentModelRepository I tried to programmatically determine the conflicts, too my surprise 0 conflicts were raised
Here is the Model and corresponding item in CMS
I currently have an open ticket with Optimizely Support and will keep this thread updated on progress,
Thank you for reporting the issue. Yes it can be a bug when cms comapre property in model sync then it looking for type of PropertyDefinitionType which is PropertyBlock<BlockData> and in this case both PetNameFormField and TextFormFieldBlock has same PropertyDefinitionType. I'll rasie a bug for it and it will be investigated soon if it is the case.
Thank you Shahram
You are experiencing this problem in Optimizely DXP in the preproduction environment?
It might be a long shot, but I would simply running another deploy! There can be problems where the deployment slots that gets swapped out hold an holder version of the code. When updating content type definitions, I always do a double-deploy...
We had tried re-deploying out again although the same issue and was able to replicate locally, it does seem like a bug, due to both the new and old types being local blocks and the Model Sync service not picking these up. I'll await Optimizely to confirm
I have now gone down the route of doing the following just so can get the team back up and running.
I've encountered issues similar to this before with this before and found the following things helped:
Version your projects: Stamp your projects with a semantic version number and increment it with each release. Optimizely CMS will recognize that version number and will ensure the database is sync'd up to the latest version when one of the load balanced instances is started up. If two instances are up and running with the same semantic version but different code bases, the CMS won't force an update.
I've also found that sometimes the DB will not update when switching slots through the Paas Portal and this has also been resolved with a full restart of the environment.
Thank you all for Input, Optimizely have just confirmed it was identified as a bug and will be resolved in release 12.9.3