Gavin, what's your response to the latest commentary above? I'm also having my unit tests fail because of this problem. My equals() method (business key equality) includes a Date field, so when I create an object, save it to the DB, load it back from the DB and compare, they are NOT equal. That's a problem.

Couldn't Hibernate either 1) create a "datetime" type that would always assign to a java.util.Date object, or 2) reflectively look at what type of variable it's assigning the value to, and return a Date if the variable is Date, or a java.sql.Timestamp if the variable's type is Timestamp?

Connor

By the way, I recognize that this is an API problem - and a hell of a stupid decision by Sun. But it's still a problem that real world users have to deal with, and Hibernate can fix this issue completely by implementing one of my suggestions (or maybe a slicker one, any ideas?)

Thanks!

I struggled with this problem, too.

I can understand, that this is a homemade problem of sun and this is not a problem of hibernate. BUT what I don't understand is, why hibernate isn't shipped with a out-of-the-box solution for this problem? Why has every user to implement his own usertype to get this problem fixed? Since no one will like to use java.sql.Timestamp in their business code, why is the java.util.Date usertype not the default - or at least in the hibernate distribution? It's a very dangerous problem because of its transparency. A hibernate user doesn't expect his date comparisons to fail because he declared it's mapping as java.util.Date - and expects not to get a java.sql.Timestamp. I thought hibernate's goal is to be less intrusive as possible - but in this case, I have to know what hibernate is actually doing with the types. All I want to say is, why give the user the burden to implement a usertype if 90% of the time a user wants a java.util.Date? Technically it might be right way to use the java.sql.Timestamp, but hibernate is a framework for the user - I think...

A migration from 1.05_06 to 1.5_11 solve the problem in my case.

Best regards,
Py

Back to the timestamp usage in Hibernate ...

Still I see another problem about using Timestamps to map a date field of the database :

I have the case where there is an index on a date field of a table (here on ORACLE 10i).
When I map it with a timestamp, my requests, containing a condition on this date filed, will not use the index anymore.

This happens because the date field is transformed automatically to a timestamp by the DB engine and for this cannot use the index.

I think, that this can be addressed by creating another index on the timestamp of the field ... if you have the possibility to do so ;o)

Nice solution anyway to use a user defined type to address this Date problem that should be enough for 99% of the cases.

Cheers,
Christophe

<property name="myDate" type="date" column="my_date"/>

hibernate then seems happy to return you a java.util.Date rather than a Timestamp. Given the age of this thread though, I'm guessing this isn't news anymore!?

ah, you might want to disregard my previous post, of course that causes the time component to be lost.

If you've not got a lot of fields where this is an issue, you can do something on your entity class like : -
public void setStartDate(Date startDate) {
this.startDate = new java.util.Date(startDate.getTime());
}

this should ensure you're always working with java.util.Date's on the java side.

You can use date and use type as timestamp in your mapping. Using timestamps means that your date can be checked and work with a simple comparison but may very well fail inside your core java application. On The business process of Java, it often uses date objects and using hibernate with timestamps usually causes some serious problems in your code.

The problem with java.sql.Timestamp is really annoying - especially for testing. The simplest test doesn't work as expected.



Entity.equal() method for entity is implemented as (such a comparison is used for tests only)



I use Hibernate as JPA provider with XML configuration and I found now way how to make Hibernate return java.util.Date instead of java.sql.Timestamp.

The only thing that helps me - is to implement entity setter as a "deep" copier



But that's not good.

I had to implements my own DateTimestampType and JdbcDateTimestampTypeDescriptor in order to get java.util.Date from Hibernate.

I use Spring/JPA/XML-config and I haven't found how to register this new type so I had to rewrite dialect I use.



Use your own package names instead of "xxx" package.