|
|
|
Custom dialects would certainly work, but custom dialects put us back into the business of havnig to add another custom dialect every time we add a supported platform. We had a custom persistence layer that we ripped out in favor of Hibernate specifically to avoid that. We support three major database platforms currently, and are planning to add more.
The date operations you list don't seem to work in HQL. I created an IntervalTracker class (attached). Using the following query returns quite different results on different db platforms: List results = executeQuery("select endDate - startDate from IntervalTracker order by id"); using MySQL this query produced a result like 1.111739E8. Using two Calendar objects to mimic the values in the database, subtracting the getTimeInMillis() values returned 3605940000. Using HQLDB returned an exception: Caused by: java.sql.SQLException: Wrong data type in statement [select intervaltr0_.enddate-intervaltr0_.startdate as col_0_0_ from intervaltracker intervaltr0_ order by intervaltr0_.id] (full stack trace attached) Using PostgreSQL also returned an exception: Caused by: org.postgresql.util.PSQLException: Bad value for type double : 41 days 17:39:00 (full stack trace attached) The patches look great. Why aren't these being considered for 3.3?
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DATETIME (the spec term for DATE, TIME, OR TIMESTAMP types) arithmetic is in fact defined by the ANSI SQL spec. Section 4.5.3 from the '92 spec defines this behavior. Basically:
DATETIME - DATETIME = INTERVAL
DATETIME +|- INTERVAL = DATETIME
INTERVAL + DATETIME = DATETIME
INTERVAL +|- INTERVAL = INTERVAL
INTERVAL *|/ NUMERIC = INTERVAL
NUMERIC * INTERVAL = INTERVAL
are all defined behaviors. I cannot say if all databases implement this all correctly however. And I am pretty sure some treat it differently in terms of what is actually calculated and returned in terms of the INTERVAL returns.