Bug #58751 DatabaseMetadata.getIndexInfo() constrains CARDINALITY to Types.INTEGER
| Submitted: | 6 Dec 2010 10:51 | Modified: | 6 Dec 2010 11:55 |
|---|---|---|---|
| Reporter: | Mark Leith | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Connector / J | Severity: | S3 (Non-critical) |
| Version: | 5.1.11 | OS: | Any |
| Assigned to: | CPU Architecture: | Any |
[6 Dec 2010 11:55]
Tonci Grgin
See Bug#44869. Pushed up to revision 1024.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.050 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.
Description: DatabaseMetadata.getIndexInfo() currently defines the CARDINALITY column as: fields[10] = new Field("", "CARDINALITY", Types.INTEGER, 10); Types.INTEGER maps to an int, which has a max of 2,147,483,647, meaning any table with more than ~2.2 billion rows breaks this mapping, as in the following example: com.mysql.jdbc.exceptions.jdbc4.MySQLDataException: '3.344700834E9' in column '11' is outside valid range for the datatype INTEGER. How to repeat: o Create a table with 2.2 billion rows within it, with a primary key o Call DatabaseMetadata.getIndexInfo() on the table (I accept that this is probably a poor test case, who wants to manually create 2.2 billion rows? :)) Suggested fix: Use Types.BIGINT instead of Types.INTEGER above.