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 On Fri, Feb 16, 2018 at 3:17 PM Hilco Wijbenga <[email protected]> wrote: > On Fri, Feb 16, 2018 at 7:41 AM, <[email protected]> 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? > > -- > 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 > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Steven Dodd Software Developer Street Contxt <http://www.streetcontxt.com/> Office: (416) 596-9011 <4165969011> Cell: (416) 889-0536 <http://static.prod.scx-it.net.s3.amazonaws.com/sig/4168890536> 154 Pearl Street, Suite 300, Toronto, ON, M5H 1L3 <https://www.google.ca/maps/place/154+Pearl+St,+Toronto,+ON+M5H+3T4/@43.6477796,-79.3876354,17z/data=!3m1!4b1!4m2!3m1!1s0x882b34d1a30d8275:0xad5ad9b5b46af576> -- 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. -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
