getExpectedJdbcType

MariaDB-specific deviations from the default type mapping:

• INT UNSIGNED does not fit an Int (0 .. 2^32 - 1), so it is read as Long, and BIGINT UNSIGNED does not fit a Long (0 .. 2^64 - 1), so it is read as java.math.BigInteger. The driver returns exactly those types for them.

• SMALLINT is read as Short, which is what the driver reports and returns for it.

• A multi-bit BIT(M) column is read as ByteArray, because that is what the driver returns for it while reporting byte[] — the source-code spelling, not the "[B" JVM binary name the default mapping looks for — as the column class. See isMultiBit and #2087.

• TINYBLOB/BLOB/MEDIUMBLOB/LONGBLOB are read as ByteArray: the driver reports java.sql.Blob as their column class while ResultSet.getObject returns a byte[] (#2087). For those columns the driver reports VARBINARY/LONGVARBINARY as the JDBC type, never java.sql.Types.BLOB, and that is what the condition keys on — so H2 in MariaDB mode, which delegates its mapping here, reports java.sql.Types.BLOB and does return real java.sql.Blob values, keeps mapping to java.sql.Blob.

Everything else falls through to DbType.getExpectedJdbcType.

The driver is also known to report java.lang.Integer for a BIGINT column whose stored values happen to fit in an Int; that case is not handled here. The SQLite analogue of it is (see Sqlite.generateConverter), so the fix pattern exists if this turns out to bite.