Consequences of changing a table field enumeration type

(0) Share

Report

Posted on by Pete Alberts

3,542

Hi folks

In ISV model XYZ we have a table with a NoYes enumeration field. There is a requirement to be able to specify N/A. I have changed the field enum type to XYZNoYesNa.

I am 100% sure that this solution will not cause any deployment issues or database corruption. However model XYZ is in use by many clients and the table holds important data. My employer and some senior developers are very concerned. I do not agree with this concern, because I am applying some very high-tech, next-gen, super-intelligent thinking: 1 is 1 and 0 is 0. But I have been pulled into the worrying thing.

I posted a similar thread quite a while ago in which the answer comes down to this not being an issue. However I need some assurance. If something goes wrong with this I will most probably be demoted to a coffee machine.

This is how the enums match up. Both are non-extensible.

	NoYes	XYZNoYesNA
No	0	0
Yes	1	1
NA		2

So after deployment of my changes. Data in that field that were "No" will remain "No". Data in the field that were "Yes" will remain "Yes". The only change is that a new value is now possible: "NA" (with integer value 2).

And then there are talks about "deployment errors" that will happen if I do this. I do not have much experience with deploying packages so I can't say for sure. But I can't think that it can be an issue.

In summary: Is there anything that can go wrong with package deployment or db synchronization if I change a table field's enum type of NoYes to XYZNoYesNA?

Thanks for your attention

I have the same question (0)

All responses (8)

Answers (4)

Martin Dráb 236,275 Most Valuable Professional on at

Like (1)

Report

RE: Consequences of changing a table field enumeration type

I didn't meant your own code - that's easy. I meant customers' customizations based on your model. You have no control over it - you don't know what you'll break and you can't fix it.

Was this reply helpful? Yes No
Suggested answer

nmaenpaa 101,160 Moderator on at

Like (1)

Report

RE: Consequences of changing a table field enumeration type

It is a breaking change. Until now anyone who extends your code can have something like "if YourField == NoYes::Yes" and that would not compile anymore if you change the field type.

Was this reply helpful? Yes No
Pete Alberts 3,542 on at

Like (0)

Report

RE: Consequences of changing a table field enumeration type

Thanks Martin. I have changed or fixed all related code to cater for this change.

Thanks Nikolaos. About the extensions: there are a few customer extensions to the model, but they are all managed by my organization. So I checked them and they do not reference this field. So from that point I am a-okay.

Thanks Sergei. Yes I'd take this on much more seriously if it was an extensible enum that is being replaced. I think I'd avoid doing that all.

Breaking change. I was not aware that this concept exists till now. I have educated myself. This one is not listed. Maybe it should've been. But then I'd disagree. Replacing NoYes with XYZNoYesNA is basically the same thing as adding a value to an enumeration (in terms of db syncing). And NoYes can't be extended.

I have deployed a package to a few test environments and the data looks good. And then I've also updated a few of our VM's with the change (some have customer extensions of model XYZ loaded).

So in terms of possible problems: 1. Compilation is fine 2. Business logic has been updated correctly 3. DB synchronization is working 4. Extensions have been checked

My employer (who is watching as I type) is still concerned that the DeployablePackage will fail or corrupt customer data. So I will have to test again on an environment with more data. You never know, maybe it works for 5 records but utterly wrecks the db for 6 records.

But then I think you guys have changed my mind. I thought this to be a quick change. I'll sleep on it. Will probably do some sort of extensive super safe method to apply the required change. (As suggested by Nikolaos.)

Thank you all, much appreciated.

Was this reply helpful? Yes No
Verified answer

Martin Dráb 236,275 Most Valuable Professional on at

Like (0)

Report
RE: Consequences of changing a table field enumeration type

It can easily lead to logical errors in code using the field. For example, let's have this code:

if (table.Field) { info("Success!") }

Originally it would show "Success" if the value was Yes. Now it'll show "Success" for NA as well. It often won't be the behaviour you want.

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,160 Moderator on at

Like (0)

Report

RE: Consequences of changing a table field enumeration type

Sergei has a good point. If your customers have some extensions that are referring to this field, those extensions could break.

Changing the enum type is a breaking change. So the proper process would be to add a new field and deprecate the old one in a controller manner.

But if you know for sure that nobody has extensions that refer to this field, then you can just change it.

Was this reply helpful? Yes No
Sergei Minozhenko 23,093 on at

Like (0)

Report

RE: Consequences of changing a table field enumeration type

Hi Pete,

But is it a breaking change from ISV side?

Was this reply helpful? Yes No
Verified answer

Sergei Minozhenko 23,093 on at

Like (0)

Report

RE: Consequences of changing a table field enumeration type

Hi Pete,

I did this kind of change many times with non-extensible enums. It works fine.

With an extensible enum, it could be quite risky especially if you need to deliver this change to many different customers. In this case, I think it's better to create a new field and replace usage in code + data upgrade.

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,160 Moderator on at

Like (0)

Report

RE: Consequences of changing a table field enumeration type

I think it should work, but of course you need to test it.

If you can do this change in your dev box and synchronize the database succesfully, that already tells you something. Next, build a deployable package and deploy it to a test system. If it goes well and existing data stays as it is, then you're good to go.

Was this reply helpful? Yes No