I wouldn't call it perfect, but probably the best that can be done using the current Java API :) We will need to keep in mind that something like this will break:


The problem I see is that the user thinks he has a java.util.Date but actually has a java.sql.Timestamp

Agreed!
BUT... do you realize that it is not obvious from the API that you will get a java.sql.Timestamp back instead of your original java.util.Date ?

Consider the following class:


The creationDateTime is supposed to record the date/time the message has been created. To persist it, I will have to map it using a timestamp, right ?



Now, suppose I create a new Message instance and set its creation time to the current time. Later - in the same session - I can compare this time with another java.util.Date without any problem:



BUT, if you reload the message object from the persistent store, the code above will always fail !
This because you don't have a java.util.Date anymore but a java.sql.Timestamp - so my code now behaves differently with transient objects and persistent/reloaded objects. Weird...


Stated differently: the Java<->DB transformation is not an actual function - it is not reversible.

This issue becomes even more important when you apply the DAO pattern where different implementations could be used. Suppose an Hibernate and an XML-file-based implementation - both will return data that looks like the same, but one has replaced dates with timestamps... How can you cope with this situation ?


So the question: how should I persist a java.util.Date with date+time precision so I can compare safely the vales with other java.util.Dates ?
AFAIK this is a very common case...

eh???

Why on earth should before() fail?

Well actually doing a comparison with .before(now) should be okay ... only equals is a problem. Which still sucks somehow.

That's right - sorry, took the wrong example :-(
Only the equals() will fail, the other methods are ok.

Cfr. above for an example breaking the equals().

This is because of the following code inside java.sql.Timestamp:


Hence this discussion ;-)

Sorry to re-open this old topic, but...

Not only does equals() fail, but compareTo() does also (at least on JDK 1.5)!

Note that compareTo() is used throughout the whole Collections framework, so TreeSet.add will fail, TreeMap.put will fail, ...

In my opinion, this is a major problem that should be solved somehow.

Regards,

Andreas

I have a mapping like this :



and the column is defined as a date-only-field.

When I want to retrieve values from the map created, I need to extract a java.util.Date-object from an Calendar-instance with all time-componenets set to null as the key, but since all keys in the map are of java.sql.Timestamp, I won't find my object.

I vote for the solution to actually return java.util.Date if this is specified in the mapping-document (specifying timastamp or java.util.Date both results in java.sql.Timestamp-objects).

Hi,

I am using DATE for the database field and type="timestamp" for the corrsponding mapping in the HBM . The java datatype is java.util.date

I am able to save a record into th DB with this setup. However when I
access the same record, update it and try to save it back, I have the following exception :

org.springframework.orm.hibernate3.HibernateOptimisticLockingFailureException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xx.xx.Reason#4]; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xx.xx.Reason#4]
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xx.xx.Reason#4]
....................................
..................................
........ at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1635)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2208)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2118)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)


The query for the update is as follows:
Hibernate: update WW_APPMT_REASON set MODIFIED_DT=?, CREATED_BY=?, CREATED_DT=?, MODIFIED_BY=?, DESCRIPTION=? where REASON_ID=? and MODIFIED_DT=?
2006-09-18 11:46:25,765 [main] DEBUG org.hibernate.type.TimestampType - binding '2006-09-18 11:46:25' to parameter: 1
2006-09-18 11:46:25,765 [main] DEBUG org.hibernate.type.LongType - binding '20' to parameter: 2
2006-09-18 11:46:25,765 [main] DEBUG org.hibernate.type.TimestampType - binding '2006-09-18 11:45:22' to parameter: 3
2006-09-18 11:46:25,765 [main] DEBUG org.hibernate.type.LongType - binding '21' to parameter: 4
2006-09-18 11:46:25,765 [main] DEBUG org.hibernate.type.StringType - binding 'Vaccination' to parameter: 5
2006-09-18 11:46:25,765 [main] DEBUG org.hibernate.type.LongType - binding '6' to parameter: 6
2006-09-18 11:46:25,765 [main] DEBUG org.hibernate.type.TimestampType - binding '2006-09-18 11:45:22' to parameter: 7

I had code blow up in a related way.

My domain loaded a "Date" object. Hibernate loaded in a sql.Timestamp implementation.

The object was then used in some struts action code using the "compareTo" method.

Result: ClassCastException.

LHS = sql.Timestamp RHS = util.Date

Workaround:
Create a DateTimeUserType to ensure the persistance layer only deals with util.Date.

Here's one problem I am facing with date/time. We have DB2 on Linux and date/timestamp fields were mapped to java.util.Date. This worked fine. Then we switched to DB2 on Mainframe and the app broke. Hibernate failed on date/time conversion. We changed the mapping to java.sql.Date and it worked.

What do you Hibernate experts think? Should I change all my existing mappings? Or should the IBM db2 driver should handle it? This is an important issue. I hope someone from Hibernate Team will answer this.

Well, I'm not on the Hibernate Team, but I'll give it a shot :)

There are a few versions of the DB2 dialect, as DB2 implementations across platforms are not consistent (thanks IBM). Try switching your dialect to DB2390Dialect and see if that clears up the problem.

Thanks Ananasi. Yes, we did switch to DB2390Dialect, but that didn't solve THIS problem. Yes, we did have other problems with the generated SQL which was taken care by switching to DB2390Dialect, but not this one.

Well, that's a new one to me then. I remember what a pain in the butt working with DB2 on AS/400 was, and I don't envy you. ;)

I'll look a bit more into it and get back to you.

What was the specific error/stacktrace when the error occurred?

Check the mainframes' date format system var. You may have to write your own dialect to handle the mainframes' specific date format string. I've had to do this in the past, and it's not tricky at all, just extend DB2390Dialect and maybe register the column type differently.