I ended up going a little different of a direction then the patch. Rather than the continued dual handling for named/ordinal in every method, I instead introduced an internal interface (internal to EnumType) to encapsulate the named/ordinal handling).
Additionally, the patch totally did away with leveraging the JDBC type which is not valid in cases where annotations are not used. There are times (granted, mostly legacy, but they still need to be accounted for) when that information is simply not known up front. In those cases we have to look at the return type from the ResultSet or the parameter type from the PreparedStatetement. So in this regard I added a kind of hybrid approach where annotation data and user config are used exclusively if provided; otherwise we fall back to similar decoding we had before.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
I ended up going a little different of a direction then the patch. Rather than the continued dual handling for named/ordinal in every method, I instead introduced an internal interface (internal to EnumType) to encapsulate the named/ordinal handling).
Additionally, the patch totally did away with leveraging the JDBC type which is not valid in cases where annotations are not used. There are times (granted, mostly legacy, but they still need to be accounted for) when that information is simply not known up front. In those cases we have to look at the return type from the ResultSet or the parameter type from the PreparedStatetement. So in this regard I added a kind of hybrid approach where annotation data and user config are used exclusively if provided; otherwise we fall back to similar decoding we had before.