db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2307) DatabaseMetaData.getTypeInfo nullability is incorrect for columns 1,7 and 9
Date Wed, 02 May 2007 18:31:15 GMT

    [ 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.


Mime
View raw message