Community
Participate
Working Groups
Build Identifier: M20110909-1335 Using dbStore with DB2 creating a sql statement with data type java.util.Date throws a SQL Exception. (Not by using dbStore with H2) We have seen, that CDO during building the sql statement is using Date#toString() which returns e.g. Thue Jun 2012. DB2 doesn't accept this date string. Reproducible: Always Steps to Reproduce: 1. Select * from aTable where validTo > aDate 2. 3.
When creating an object is in the CDOQuery CDOQueryImpl class in a hashmap of the columns of a table name as key and the object type is set as a value. Especially in our case it is the table column named validTo and an object of type java.util.Date. HashMap # Entry #HashMap toString returns validTo = Thu Jun 21 09:16:46 EDT 2012th With this format of date strings deals dbStore with H2, but not deal with DB2. In CDODataOutputImpl at line 413 of a CDOTypeImpl CDOModelUtil getPrimitveType # () is set as org.eclipse.emf.cdo.common.model.CDOType.Date. This value is set in line 191 org.eclipse.emf.cdo.server.internal.db.SQLQueryHandler in the class in the prepared statement. This is in line 258, the exception "problem while executing SQL query:" thrown.
commit d21666610ed6f93201f660b323d286ac18259fe6 Unfortunately this fix breaks queries for TIMESTAMP columns because java.sql.Date does not contain (or suppresses) the time portion. Investigating...
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.
There is also this problem with a PostgreSQL backend. The unit test SQLQueryTest#testDateParameter failed with an SQL Exception. Conversion error between java.util.Date an the type java.sql.Date
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. In particular query parameter value conversion is now delegated to the DBAdapter and can be adjusted there.
Closing.
