Closed Noremac201 closed 1 month ago
@Noremac201 Thanks for the detailed and clear report.
The question is, can we either bring down the 100,000 addition to 32,000 ? Would that be a breaking change?
Yeah, I don't think we can safely do that. It could be that there are applications out there that have these type codes hard coded, and changing the actual type code to something else in the driver could then lead to failures, as the driver checks that the type code that an application uses is valid.
I do however think that we can fix this in a different way:
short
. This type code will be the unchecked value of (short) VENDOR_TYPE_CODE
. For JSON, this will be -31061
.short
vendor code and the normal vendor code to be used.DatabaseMetadata#getTypeInfo()
. This means that anyone calling ResultSet#getShort("DATA_TYPE")
will get the short vendor code, and can freely use that with the driver.
Environment details
2.20.1
Steps to reproduce
Code example
When Datanucleus attempts to load a JDBC connection, it will get the Type info from the connection, however, this type info is then immediately cast to a
short
in Datanucleus (1). However, with Google SQL and support for JSON it will crash upon trying to convert100011
to a short, which is coming from the JSON vendor type number (2).Stack trace
The question is, can we either bring down the 100,000 addition to 32,000 ? Would that be a breaking change? This would ensure compatibility to those jdbc loaders who assume JDBC types are very small always.