I have updated a cdt and added an extra column to it. There are few thousands of instances in the old version of the cdt where the extra field is not present. In the process instance as well the cdt is showing in cap sign which means it's referring to the old version. I have done a data migration to populate that extra field for the old instances. However, while writing the data to the table through the process, even though the new column is not present in the old cdt, the database column is getting overwritten by null value.
Is there any way how to avoid this scenario?
Can you try by setting CDT-->Field attribute, nillable =false?
The nillable attribute of an element is retained. When a field with a null value is encountered, the element is not created.
Else need to handle by adding DB constraint.
Sushil Kapoor Thanks for your reply.
I am afraid, if I make the nillable = false, it would behave like a "required" field and it might break if there are any actual null values.
I fear there is not a very clean solution for this. The one time I had to deal with something similar to this, luckily the particular CDT in question was always being written to DB in its own special subprocess which just contained the WTDS node -- in which case, i updated the WTDS subprocess to add a step right before the WTDS node to check whether the newly-added CDT field was empty, and if so, attempt to re-query the value of that column for that DB entry, before executing the update. Unfortunately if your WTDS nodes are directly contained in your already-running instances, then that means you'd need to edit instances manually to handle this.
Honestly I think your best bet at this point would be to keep a backup copy of what all the values should be, perhaps in a local file or perhaps in a separate database, and then each time a running instance finishes, either manually check it and revert the overwritten value, or create a special process to do this for you. If you have a single specific subprocess that always runs right at the end of a given legacy instance, for example, this could be a good target for an automated cleanup option.
Thanks Mike. We have been doing the manual data migration so far which is not the best practice. Unfortunately, the WTDS node is in the running instances so can't even modify that.I think My best option at this point of time would be to cancel all the running instances and restart them. Any alternate solution is also welcome.
I've heard of some plug-in which allows designers to update running instances with a new version in some way - but I've not personally used it so I'm not sure how extensively or how well it works (or even if it still works for modern versions). But it might be worth looking into, especially if the only thing that's changed for most models is the CDT version in question.
Discussion posts and replies are publicly visible
© 2020 Appian. All rights reserved.