Re: 3.0.8 ResultSet.getObject returns java.lang.Long - Jeff Miller - com.mysql.lists.java

5 messages in com.mysql.lists.javaRe: 3.0.8 ResultSet.getObject returns...

From	Sent On	Attachments
Jeff Miller	04 Oct 2003 10:38
Mark Matthews	04 Oct 2003 11:11
Jeff Miller	04 Oct 2003 11:29
Mark Matthews	04 Oct 2003 12:03
Jeff Miller	04 Oct 2003 12:37

Subject:	Re: 3.0.8 ResultSet.getObject returns java.lang.Long
From:	Jeff Miller (j_e_...@yahoo.com)
Date:	10/04/2003 11:29:00 AM
List:	com.mysql.lists.java

I don't have a simple test case for you to try.

I now realize that the problem is with the integer values returned for auto-generated keys. INTEGER columns declared with AUTO_INCRMENT return java.lang.Long from ResultSet.getObject when retrieving auto-generated keys via PreparedStatement.getGeneratedKeys().

Example:

CREATE TABLE Account ( accountNumber INTEGER NOT NULL AUTO_INCREMENT, ... );

Prepared statement = connection.prepareStatement( "INSERT INTO Account VALUES(?, ...)", keyNames); statement.setObject(1, 0); ... statement.execute(); ResultSet rs = statement.getGeneratedKeys(); rs.getObject(1); // 3.0.8 returns Long, 3.0.7 returns Integer

Jeff --- Mark Matthews <ma...@mysql.com> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Jeff Miller wrote:

It appears that recent versions of mysql connector ResultSet.getObject returns different Java types for INT columns: - mysql-connector-java-3.0.7-stable returns java.lang.Integer - mysql-connector-java-3.0.8-stable returns java.lang.Long

The mysql 4.0.12 manual states that an INT column is 4 bytes with a range of -2147483648 to 2147483647. If so, then java.lang.Long is overkill and java.lang.Integer seems more appropriate.

Will future versions of ResultSet.getObject continue to return java.lang.Long for INT columns or will it be changed to return java.lang.Integer as in version 3.0.7?

http://shopping.yahoo.com

Do you have a testcase? I can't seem to reproduce the issue on my end (i.e. the driver returns 'java.lang.Integer' when I call getObject() on INT fields).

Your columns doesn't happen to be 'UNSIGNED' do they, or are they involved in any calculations (which can change the type that MySQL reports to the driver in some cases)?

The testcase I'm using on my end is (in JUnit form):

public void testIntShouldReturnLong() throws Exception { try { this.stmt.executeUpdate("DROP TABLE IF EXISTS testIntRetLong"); this.stmt.executeUpdate("CREATE TABLE testIntRetLong(field1 INT)"); this.stmt.executeUpdate("INSERT INTO testIntRetLong VALUES (1)");

this.rs = this.stmt.executeQuery("SELECT * FROM testIntRetLong"); this.rs.next();

assertTrue(this.rs.getObject(1).getClass().equals(java.lang.Integer.class));

} finally { if (this.rs != null) { try { rs.close(); } catch (SQLException sqlEx) { // ignore }

this.rs = null; }

this.stmt.executeUpdate("DROP TABLE IF EXISTS testIntRetLong");

} }

Regards,

-Mark

- -- Mr. Mark Matthews MySQL AB, Software Development Manager, J2EE and Windows Platforms Office: +1 708 557 2388 www.mysql.com

Are you MySQL Certified? http://www.mysql.com/certification/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/fw1ytvXNTca6JD8RAr32AJsFkvn60366Fg1dpKNWuMaj71dZ9ACeOqQ5 fJxIJyNt88zBS4q9/AhWHWA= =fdKN -----END PGP SIGNATURE-----