Handling unknown enum values

[st...@streetcontxt.com]

We have a fairly common forwards-compatibility scenario that makes using enums problematic: loading unknown enum values results in an exception during loading.

These "unknown" enum values are just values written by "future" versions of our application.

In cases where it really matters, we use feature flagging to ensure such values don't get written until old versions of the application are shutdown. 

However, there are many cases where we'd really just like the unknown value to be loaded as "unknown", and not cause loading to fail.

Of course, we can always handle "enums" by just treating them as strings, but that approach loses out on type safety in Java/Scala and schema validation in the database.

A couple of alternate approaches I've been wondering about:

1. Load/store enums as Either<Integer, EnumType> or Either<String, EnumType> (depending on the underlying database enum type). This approach allows the client to inspect the unknown value if need be, round-trip it, or pass it along if it doesn't really need to know about the enum values.

2. Map unknown enum values to a customizable UNKNOWN enum value. This could be built into jOOQ generated enum types, and configurable for user-generated enum types. This approach wouldn't allow for client inspection of the unknown value, or passing it along, or round tripping - store operations would have to fail when trying to store such an unknown value.

Looking for some feedback on those approaches, and whether they can be implemented in jOOQ 3.10 through customization, and whether some variation of the above might make sense to be built into jOOQ?

Thanks!

This e-mail message is intended for the named recipient(s) above, and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please do not read the content. Instead, immediately notify the sender and delete this e-mail message. Any unauthorized use, disclosure or distribution is strictly prohibited. Quantify Labs Inc and the sender assume no responsibility for any errors, omissions, or readers' misinterpretations and/ or understanding of the content or transmission of this email.

[Lukas Eder]

2018-02-16 16:41 GMT+01:00 <st...@streetcontxt.com>:

Looking for some feedback on those approaches,

That certainly does sound very interesting - I'll lurk and see whether the community has some feedback...

 

and whether they can be implemented in jOOQ 3.10 through customization,

Sure, looks like a job for either custom Converter or Binding types:

https://www.jooq.org/doc/latest/manual/code-generation/custom-data-types

https://www.jooq.org/doc/latest/manual/code-generation/custom-data-type-bindings

I'll be happy to answer any specific questions that you may have.

 

and whether some variation of the above might make sense to be built into jOOQ?

At this stage, I feel like an out-of-the-box solution from jOOQ might be over engineered.

Thanks,

Lukas

[st...@streetcontxt.com]

I'll look into the customization approaches you mentioned.

Appreciate the quick response!

Cheers,

Steve

[Hilco Wijbenga]

On Fri, Feb 16, 2018 at 7:41 AM, <st...@streetcontxt.com> wrote:
> We have a fairly common forwards-compatibility scenario that makes using
> enums problematic: loading unknown enum values results in an exception
> during loading.

I'm not entirely clear on your environment and deployment strategy. So
I'll take a guess:

1. There is no change to the database structure;
2. There is a new entry in some Java enum in the "future" application;
3. Loading a record generated by the "future" application in a
"current/old" application will fail to translate to the correct enum
entry as it does not exist in the "current/old" application.

If I am correct then it might be possible to avoid the whole problem
by breaking it up:

1. Add the new enum entry to the application;
2. Deploy the application with the new enum entry added (but nothing
uses it yet);
3. Add the functionality that uses the new enum entry;
4. Deploy the full "future" application.

Would that work for you?

[Steve Dodd]

Yes, that approach works - it's along the lines of what I was alluding to when I mentioned "feature flagging".

The challenge is that in some situations, the drag incurred by going through those motions seems excessive and could be avoided through one of the alternatives I proposed originally (or even just saving and loading as a String, and leaving it up to business logic to translate to/from enums if it wants to).

I'm moving on to other things for the time being. I'll post again if I work out the custom convertor to Either<String, EnumType> at some point in the future.

Thanks for your help!

Steve

--
You received this message because you are subscribed to a topic in the Google Groups "jOOQ User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jooq-user/uNdEnbmBNS4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Steven Dodd

Software Developer

Street Contxt

Office: (416) 596-9011

Cell: (416) 889-0536

154 Pearl Street, Suite 300, Toronto, ON, M5H 1L3