Hi again. I have a new issue that I would appreciate if you could have a look at. My widget differs between the dev workspace and the client workspaces (see pictures). I have created a release and roll out brick. I tried all three settings for the synchronize_ldm parameter, but no change. I also synchronised the clients via the api call, with no change. The LDM is as far as I can see the same and the answer scale attribute is an integer in both the dev and the client workspace when looking at the data type. However, it seems to be read as text in the client workspace, since the sorting changes. Earlier I had an issue with "Error during k8s execution: Unable to migrate LDM, reason(s): invalid input syntax for type integer: """ , and not being able to roll out the brick, but that was (or I thought it was) solved by changing the synchronise_ldm parameter , so was able to roll out, but I think this problem appeared then as well. Let me know if you need more details or anything to investigate this. Thanks in advance for your help!

Could you please invite user michal.hauzirek@gooddata.com as admin to: • the dev workspace • the client workspace • the latest master workspace on prod? I think you are right that the issue is in the sorting, so I would like to check how it is configured in those three workspaces and where it got lost.

Yes, of course. I've invited you to the client workspace and latest master workspace. You were already a user on dev from a previous support ticket.

Thank you, I think I now see what is the issue. I can see that the data type is correct in the DEV as well as in the master workspaces and is only incorrect in the client workspace(s)? Probably where the data present did not allow to convert the data type. In the client workspace when you applied the rollout (which included the change of data type of the column to integer), it probably tried to perform this operation with the data already loaded to the dataset. But this data-type conversion failed because there was an empty value (already loaded in GoodData) which it was not possible to convert to integer. (for some technical reason attributes can be empty if they have varchar data type but can not be empty if they are integers). That was that

invalid input syntax for type integer

error you were getting. You probably fixed that by reloading the data without empty value, but that itself did not resume the data type change. So the conversion never finished and the column remained varchar (and therefore it is still sorting alphabetically). You can tell that there was some issue in the synchronization (publishing of the model changes) if you go to the Manage section and check the history there. There is no synchronization operation that would end without error. You can do this to fix that: Option one - (if there is no empty value in the data anymore) - which seems to be the case 1. go to https://brandranalytics.on.gooddata.com/gdc/md/i57o7ciy7dqqu3ecynq8fjkz3bxd0bsb/ldm/manage2 2. paste

SYNCHRONIZE {dataset.vanswers} PRESERVE DATA;

into the text field there 3. click submit. (this will attempt to change the data type of the attribute again and it should succeed if there is no offending values.) and this will keep the data loaded as they are 4. repeat this for other client workspaces if they are also affected (just change the part after /gdc/md to the ID of each workspace Option two - if there would still be data which can not be converted to integer do the same as in “option one” but in step 2. remove the “`PRESERVE DATA`” part - that is paste there

SYNCHRONIZE {dataset.vanswers};

This will cause the data for this dataset will be removed and the data type synchronization will happen again. You will then need to reload the data for this dataset. I am sorry for the troubles here. I understand that is a bit tricky and confusing. Our engineers are already working on a fix to the LCM that would automatically do the force the cleanup of the dataset data during model change deployment if would end up in this kind of error, so in the future this will not be an issue anymore. But this will take some more time to deploy. In the meantime, please be careful when doing data type changes or primary key changes with data already loaded. I checked the other datasets in the client workspace for you and the other ones all seem fine.

Hello @Michal Hauzírek. Thank you so much for the explanation and solution. I implemented option one and it worked. 🙌