> Err, could you please describe in short what exactly you did? It seems
> that java.util.Date will now be passed right through to the JDBC driver
> from the mapping layer.
>
> If that's the case, I'm afraid the postgresql JDBC driver won't be able
> to handle this. That's o.k., I can provide a set of ExtendedType
> implementation to handle the conversion to the various java.sql Date
> types.
>
> This fuzzing around with Dates makes me go crazy :-(
In fact I didn't change any of the internal working (except for default
reengineering as java.util.Date). All the changes were in the tests, to
make them work with mapped java.util.Date and correct column type.
The way it works (and worked before) is DbEntity's attributes (table
columns) map to the correct DB date type (TIMESTAMP, TIME, or DATE).
ObjEntity's attributes are mapped to java.util.Date, no matter what the
underlying DbAttribute is. So basically, when JDBC reads a java.sql.Time,
it is converted to java.util.Date by the existing UtilDateType. This
conversion does not rely on any database-specific features. As long as
target database's ResultSet.readXYZ is implemented for all 3 date-related
types.
So there shouldn't be a need for new ExtendedType.
Andrus
This archive was generated by hypermail 2.0.0 : Fri Feb 07 2003 - 12:15:33 EST