Community
Participate
Working Groups
I get 13 errors/failures when I run AllTestsDBMysql on my setup, which is as follows: (Note that I had to patch for bug 322969 to make this test suite run in the first place.) MySQL 5.1.47 Linux 2.6.34 com.mysql.jdbc_5.1.7.201006111745.jar I'll attach the full test results in a minute, but here's an executive summary: Data truncation: Data too long for column 'testField1' at row 1 (2 times) Data truncation: Data too long for column 'testField1' at row 1 Data truncation: Out of range value for column 'testField0' at row 1 Error with type DOUBLE expected:<1.7976931348623157E308> but was:<Infinity> Error with type DATE expected:<-62167503600000> but was:<-62072809200000> Committing too long data did not result in an exception Illegal operation on empty result set. (5 times) Table 'test_repo1.PRODUCT1' doesn't exist (4 times) Table 'test_repo1.CUSTOMER' doesn't exist
Created attachment 176861 [details] Test failures
Subproblem A: Data truncations A.1 Net4jDBTest.testBinary This method creates a BINARY(1) column in the MySQL database, which means a single byte, then attempts to write a blob of 100 bytes into it. Doesn't make sense.. I wonder why it works on other databases. A.2 Net4jDBTest.testBlob Here, test logic looks sane. It sets up a 1,000,000 byte array to be written into a BLOB field. I have no idea what the problem is. A.3 Net4jDBTest.testFloat This method attempts to write java.lang.Float.MAX_VALUE into a FLOAT field in the database. The value is 3.4028235E+38, and, on my platform in any case, that doesn't fit. I think it's the precision (rather than the magnitude) that is the problem.
Subproblem B: MySQLSyntaxErrorExceptions (missing tables PRODUCT1 and CUSTOMER) An issue of case sensitivity. The query is hardcoded all-caps in the test, but MySQL on Linux treats table names as case sensitive.
Subproblem C: Illegal operation on empty result set First-level problem is same as B. DBAnnotationsTest uses hard-coded all-caps table names 'CATEGORY', 'SUBJECT' and 'PRODUCT1'. This fails to identify a table with MySQL on Linux. (Although I am wondering why these tests worked in 3.0... I haven't changed my MySQL config.) Having "fixed" this temporarily by hard-coding case sensitive table names instead, the tests run but fail because several of the annotations are (apparently) not honored by the database.
(In reply to comment #4) > (Although I am wondering why these tests worked in 3.0... I meant: in 2.0, cause in 3.0 they're broken just fine. But I guess we didn't have these tests in 2.0, did we?
Subproblem C, continued: The 'columnLength' annotation isn't honored because the MYSQLAdapter overrides getTypeName(IDBField) to substitute LONGTEXT for VARCHAR, and LONGTEXT is not a type that can be parameterized with a precision.
Adding Kai Schlamp to the CC list, as I realized that much of the code that is involved in these test errors/failures, was developed by him.
Subproblem C, continued: The 'type' annotation isn't honored because it's tested with value "CLOB" for the annotation; this too (like VARCHAR above) is replaced with LONGTEXT, by MYSQLAdapter's override of getTypeName. And so the test logic's assertion detects a diffence between the type requested through the annotation, and the actual type used.
Subproblem C, recapped: C.1 'columnLength' annotation not honored: due to type override in MYSQLAdapter: VARCHAR(n) -> LONGTEXT, see above. C.2 'columnType' annotation not honored: due to type override in MYSQLAdapter: CLOB -> LONGTEXT, see above. C.3 'tableName' annotation not honored: case sensitivity problem in test assertion (table name hard-coded all-caps)
A.1, A.2, A.3, see above. A.4 Net4jDBTest.testDouble "Error with type DOUBLE". Writing Double.MAX_VALUE to MySQL through the JDBC driver is accepted; but when the same value is read back through JDBC, it is "Infinity" rather than the value originally passed. A.5 Net4jDBTest.testDate The dates created in the Java code are 21-4-2010, 21-4-1950, 31-12-2030, and 00-00-0000 (whatever that means). But right before execution, the INSERT statement is seen to contain values (2010-05-21, 1950-05-21, 2031-01-31, 0002-12-31). So something is amiss even before the database is accessed. The way the dates are constructed looks suspicious to me, using milliseconds taken from GregorianCalendar instances. Shouldn't we be using java.sql.Date instances?
see my comment on Bug 322778
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems. Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2.
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
I assume that this is fixed now with the changes of bug 546872.
Closing.
