Bug #83368 5.1.40 regression: wasNull not updated when calling getInt for a bit column
Submitted: 13 Oct 2016 12:17 Modified: 20 Apr 2017 21:03
Reporter: Maia Everett Email Updates:
Status: Closed Impact on me:
Category:Connector / J Severity:S2 (Serious)
Version:5.1.40 OS:Any
Assigned to: Filipe Silva CPU Architecture:Any

[13 Oct 2016 12:17] Maia Everett
5.1.40 added a new method to ResultSetImpl, getNumericRepresentationOfSQLBitType(), which is now called from getInt() and getLong() as (apparently) a shortcut code path when the underlying column type is BIT.

Unfortunately, it does not update wasNullFlag. Therefore, when calling wasNull() after getInt() on a bit column, it actually returns the wasNull() flag for the previous value queried.

Therefore, calling code that checks wasNull() can incorrectly assume that the returned BIT value was null.

How to repeat:
Create a table with a row that has a null value and a non-null bit column value. Query a ResultSet for the null value first, then query the bit value with getInt(). Afterwards, wasNull() will return true when it should return false.

Suggested fix:
Insert a null column value check into getNumericRepresentationOfSQLBitType().
[13 Oct 2016 12:19] Maia Everett
This minimal application works correctly with 5.1.39 and incorrectly with 5.1.40.

Attachment: BitColumnBug.java (text/x-java-source), 1.57 KiB.

[13 Oct 2016 12:21] Maia Everett
For the above application:

Expected output (and actual output with 5.1.39):

Expected: value 1 = null, wasNull = true; actual: null, wasNull = true
Expected: value 2 = 0, wasNull = false; actual: 0, wasNull = false

Output with 5.1.40:

Expected: value 1 = null, wasNull = true; actual: null, wasNull = true
Expected: value 2 = 0, wasNull = false; actual: 0, wasNull = true
[13 Oct 2016 12:23] Maia Everett

Attachment: getNumericRepresentationOfSQLBitType-NullCheck.patch (text/x-patch), 751 bytes.

[13 Oct 2016 12:35] Maia Everett
Correction: getNumericRepresentationOfSQLBitType() existed before, but now it is called from getShort(), getInt() and getLong() for a BIT column type. I'm not very familiar with the codebase, and thus not sure if the attached patch is actually the right way to fix the issue, but it seems so to me.
[13 Oct 2016 13:00] MySQL Verification Team
Hello Maia Everett,

Thank you for the report and test case.
Verified as described.

[20 Apr 2017 21:03] Daniel So
Added the following entry to the Connector/J 5.1.42 changelog:

"After a BIT value had been retrieved from a result set, the wasNull() method
of the result set returned value for the last wasNull() query instead of the
value for the last retrieved column."