[
https://issues.apache.org/jira/browse/DERBY-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493167
]
A B commented on DERBY-2307:
----------------------------
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,
true, true,
true, true,
true, true,
true
};
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:
3. PRECISION
10. UNSIGNED_ATTRIBUTE
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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsqlgettypeinfo.asp
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")?
> DatabaseMetaData.getTypeInfo nullability is incorrect for columns 1,7 and 9
> ---------------------------------------------------------------------------
>
> Key: DERBY-2307
> URL: https://issues.apache.org/jira/browse/DERBY-2307
> Project: Derby
> Issue Type: Bug
> Components: JDBC, SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.0.0
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> Columns TYPE_NAME, NULLABLE, SEARCHABLE are returned as nullable but should
> not be. ODBC variant correctly makes these non-nullable.
> From a quick look at the metadata query this may in fact be a language issue.
> The query is based upon a VALUES clauses that has a list of literals that are
> not NULL in these columns. Thus one would expect the implied type definition
> to be not nullable. However some of the columns, e.g. 2 DATA_TYPE, have a
> similar list of non-NULL literals are do appear as non-NULLABLE with
> getTypeInfo. Not sure what leads to the different behaviour.
> Look for comments in DatabaseMetaDataTest.testGetTypeInfo() with this bug
> number for code t hat shows the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
