Closed dynamobi-build closed 12 years ago
[author="jpham", created="Thu, 28 Sep 2006 13:17:05 -0500 (GMT-05:00)"]
The exact message of the last trace was:
Sep 28, 2006 1:17:48 PM net.sf.farrago.db.FarragoDbSession rollbackImpl
INFO: rollback
Even if a value is returned by the result set and the assertEquals fails, then the test case also hangs. So it might either be related to the test harness, or something about how the test harness calls into Jdbc.
[author="jpham", created="Thu, 28 Sep 2006 15:53:57 -0500 (GMT-05:00)"]
No wonder this error was so undebuggable. The test case explicity runs tests using the Fennel Calc. And since the Fennel Calc hasn't been updated to use the new date/time/timestamp conventions, the test will fail. Fennel probably raises helpful assertions which are gobbled by the Junit framework. But they gave Junit indigestion.
The test cases seem to work with Java Calc so I will just disable the test case for now and leave it as a good integration test case for Fennel Calc later on. Not sure who to assign the bug to...
[author="jpham", created="Fri, 29 Sep 2006 16:25:04 -0500 (GMT-05:00)"]
The related tests are:
FarragoJdbcTest
SqlOperatorsTest
farrago/unitsql/expressions/datetime.sql
[author="jpham", created="Sun, 8 Oct 2006 13:59:45 -0500 (GMT-05:00)"] Closing this since Farrago will revert back to old Fennel timestamp behavior.
[reporter="jpham", created="Thu, 28 Sep 2006 13:05:31 -0500 (GMT-05:00)"] (Old title was) FarragoJdbcTest.testDataTypes hangs if there is a resultSet error)
I'm not sure whether this is problem is limited to the test harness or if it could occur outside test situations.
When one fetches data through a Jdbc result set, it usually goes through org.eigenbase.util14.AbstractResultSet.java. One uses method such as getDate(), which in turn relies on methods like toDate(). The method toDate() casts a raw object, which may be of any type, into the desired type, such as Date.
In general, the methods are written according to this idiom:
if (o instanceof TypeA) {
...
} else if (o instance of TypeB) {
...
} else {
throw new ConversionError(...)
}
If an unexpected raw data type is encountered, and it cannot be casted to the desired type, then a ConversionError is thrown. Since it is such a common pattern, I expect that it must be well tested. But somehow, when I was missing a required conversion, I was getting a hang, with the last message sent to the trace being something to the effect of "Database... rollbackImpl".