[Bug] findColumn throws NullPointerException instead of SQLException for an unknown column name
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start at IoTDBRpcDataSet.findColumn and compare it with the existing findColumnNameByIndex guard, then trace the JDBC boundary through IoTDBJDBCResultSet.findColumn and SessionDataSet.DataIterator.findColumn. Check IoTDBJDBCDataSet.findColumn as well; done means an unknown column produces a SQLException naming the missing column rather than a NullPointerException.
Written by the indexing model from the issue text.
Description
Search before asking
- I searched in the issues and found nothing similar.
Version
master (2.0.x). The affected code is also present in released 2.0.x versions.
Describe the bug and provide the minimal reproduce step
IoTDBRpcDataSet.findColumn(String) returns columnOrdinalMap.get(columnName) directly. When the column name is not present, Map<String, Integer>.get returns null, which auto-unboxes to int and throws a NullPointerException. The JDBC contract (ResultSet.findColumn) requires a SQLException when the column is not found, and the sibling findColumnNameByIndex already guards its input and throws — the guard was simply omitted for findColumn.
This surfaces at the JDBC boundary (IoTDBJDBCResultSet.findColumn) and through SessionDataSet.DataIterator.findColumn, both of which delegate to the method above. The same missing guard also exists in IoTDBJDBCDataSet.findColumn.
Minimal reproduce step:
- Execute any query over JDBC and obtain the
ResultSet. - Call
resultSet.findColumn("a_column_name_that_is_not_in_the_result"). - A raw
NullPointerExceptionis thrown instead of aSQLException.
What did you expect to see?
findColumn throws a SQLException (at the JDBC boundary) that names the missing column, per the ResultSet.findColumn contract.
What did you see instead?
A NullPointerException, from unboxing the null returned by the column-ordinal map lookup.
Anything else?
The fix mirrors the existing findColumnNameByIndex guard: throw a checked StatementExecutionException at the rpc layer (reusing the existing UNKNOWN_COLUMN_NAME message), converted to SQLException at the JDBC boundary. I'd like to work on this and will open a PR (which also fixes the identical, currently-unused-but-public IoTDBJDBCDataSet.findColumn).
Are you willing to submit a PR?
- I'm willing to submit a PR!
- Dominant language
- Java
- Stars
- 6.4k
- Forks
- 1.2k
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 129
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/iotdb
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
IoTDB Edge: stop-edge.sh does not stop its own process when IOTDB_HOME is set, and reports success Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
opensearch-project/k-NN#3597 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100