Thanks for the reply, Dan.
So given that the expected (and currently returned) nullability values for getTypeInfo() are listed in DatabaseMetaDataTest.java as:
boolean JDBC_COLUMN_NULLABILITY =
false, false, true, true,
true, true, false, false,
false, true, false,
would this mean that there are other columns with incorrect nullability, as well? Not just columns 1, 7, and 9? More specifically, none of the following columns have the words "may be null" next to them, but return "true" for the nullability according to the above array:
12. AUTO_INCREMENT boolean => can it be used for an auto-increment value.
14. MINIMUM_SCALE short => minimum scale supported
15. MAXIMUM_SCALE short => maximum scale supported
16. SQL_DATA_TYPE int => unused
17. SQL_DATETIME_SUB int => unused
18. NUM_PREC_RADIX int => usually 2 or 10
So are all of these wrong, as well?
Note that the ODBC API does things in the opposite way: it specifies "NOT NULL" where a column is not allowed to be null and then the assumption is that all other columns can be null:
And based on that API all of the above would be correct, leaving only columns 1, 7, and 9 as the issues (which is what the summary for this Jira says).
That's convenient--but I've been told numerous times before that ODBC is not JDBC, so they are not to be compared. In that case...am I right in thinking that all of the above should be returning nullability "false", too?
In case you're wondering why I'm bring this up, it's because I was looking at the patch for DERBY-2280 and noticed that Saurabh is seeing a test failure that is related to this discussion. More specifically, the nullability for AUTO_INCREMENT and UNSIGNED_ATTRIBUTE is changing as a result of his patch; but I can't tell if the nullability of those columns is correct as it is ("true"), or if Saurabh's patch is actually making them correct ("false")?