Hibernate Books

All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: DateTime
PostPosted: Mon Feb 02, 2004 10:30 am 
Senior
Senior

Joined: Sun Jan 04, 2004 2:46 pm
Posts: 147
When I have a DateTime field in a database do I have to use the Calendar type in my hibernate objects/mappings to retrieve the date and time. At the moment I am just using java.util.Date which, when persisting, will eat the time component and leave the date only.

Should I be using a Calendar type for datetimes or am I doing something else wrong?

Cheers.

Myk.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 10:31 am 
Hibernate Team
Hibernate Team

Joined: Tue Sep 09, 2003 2:10 pm
Posts: 3246
Location: Passau, Germany
You can use Date and use type="timestamp" in your mapping


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 11:13 am 
Senior
Senior

Joined: Sun Jan 04, 2004 2:46 pm
Posts: 147
Thanks for the quick reply.

For anyone else reading this for the same problem the "timestamp" type used in the mapping file still means you can use java.util.Date in your objects AND use DateTime ( SQL Server ) column type for readability of the db.

Thanks again.

Myk.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 11:24 am 
Proxool Developer
Proxool Developer

Joined: Tue Aug 26, 2003 10:42 am
Posts: 373
Location: Belgium
Myk wrote:
For anyone else reading this for the same problem the "timestamp" type used in the mapping file still means you can use java.util.Date in your objects AND use DateTime ( SQL Server ) column type for readability of the db.


This is not completly true!
Try the following sample code:

Code:
        java.util.Date date = new java.util.Date();
        java.sql.Timestamp tstamp = new java.sql.Timestamp( date.getTime() );

        System.out.println("tstamp.equals(date): " + tstamp.equals(date));
        System.out.println("date.equals(tstamp): " + date.equals(tstamp));


The output is:
Code:
        tstamp.equals(date): false
        date.equals(tstamp): true


... and you would expect both to be TRUE !

Using timestamps means your date comparaisons will work on the database but fail inside your JAVA application. Refer to http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Timestamp.html for more information...


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 11:30 am 
Hibernate Team
Hibernate Team

Joined: Tue Sep 09, 2003 2:10 pm
Posts: 3246
Location: Passau, Germany
Well thats a known problem of java.util.Date and java.sql.Date/Timestamp. This is not a problem however if you stick to one of them, and do not compare them to each other. And after all this is not a Hibernate problem at all.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 11:41 am 
Proxool Developer
Proxool Developer

Joined: Tue Aug 26, 2003 10:42 am
Posts: 373
Location: Belgium
gloeglm wrote:
Well thats a known problem of java.util.Date and java.sql.Date/Timestamp. This is not a problem however if you stick to one of them, and do not compare them to each other. And after all this is not a Hibernate problem at all.


Not saying it is an Hibernate problem...

Unfortunately, your Java application - inside its business part - often uses java.util.Date objects. If you tell Hibernate to map them with timestamps, you must be ready to face some problems at other places in your code. And you won't notice it since java.sql.Timestamp inherits from java.util.Date...

According to me, the safest approach is to define your own DateTime UserType. This user type would convert from java.util.Date to java.sql.Timestamp when persisting your data.
This way you have the best of both worlds: timestamp precision in your database (meaning date + time) while having a 'normal' java.util.Date inside your code. No need to worry anymore.

I can paste the code of such UserType here if needed...


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 11:44 am 
Proxool Developer
Proxool Developer

Joined: Tue Aug 26, 2003 10:42 am
Posts: 373
Location: Belgium
gloeglm wrote:
Well thats a known problem of java.util.Date and java.sql.Date/Timestamp. This is not a problem however if you stick to one of them, and do not compare them to each other. And after all this is not a Hibernate problem at all.


BTW: People with experience in writing JDBC code are propably aware of this issue, but the others surely not... Moreover Hibernate is there to shield ourselves from the JDBC particularities - too bad to be hit by such 'known' problem :-(


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 11:44 am 
Hibernate Team
Hibernate Team

Joined: Tue Sep 09, 2003 2:10 pm
Posts: 3246
Location: Passau, Germany
Hello? Of course using type="timestamp" means you can use java.util.Date in your code and have hibernate convert them to java.sql.Timestamp when persisting. Just take a look at the source of net.sf.hibernate.type.TimestampType


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 11:53 am 
Proxool Developer
Proxool Developer

Joined: Tue Aug 26, 2003 10:42 am
Posts: 373
Location: Belgium
TimestampType contains the following:

Code:
   public Object get(ResultSet rs, String name) throws SQLException {
      return rs.getTimestamp(name);
   }


Which means it will return java.sql.Timestamp instances;
Which means all other comparaison you will made with java.util.Date will fail.

That's my point: I want to have Date/time precision in my persistent store AND be able to compare the retrieved data with other java.util.Date instances...

You won't have any problem if you are using java.sql.Timestamp everywhere in your code...


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 12:08 pm 
Hibernate Team
Hibernate Team

Joined: Tue Sep 09, 2003 2:10 pm
Posts: 3246
Location: Passau, Germany
Oh yes, you are right, sorry, I did not notice that. That could really produce some nasty bugs. However I can't really think about a way around that ... if we just return a java.util.Date we will break code for everybody actually using java.sql.Timestamp and will loose nanosecond precission. It all comes down to that crappy implementation in the java API. That hierarchy is really broken ...


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 12:14 pm 
Hibernate Team
Hibernate Team

Joined: Tue Sep 09, 2003 2:10 pm
Posts: 3246
Location: Passau, Germany
probably the cleanest way would be to create two seperate types for mapping java.sql.Timestamps and java.util.Dates - don't know, really


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 12:17 pm 
Proxool Developer
Proxool Developer

Joined: Tue Aug 26, 2003 10:42 am
Posts: 373
Location: Belgium
gloeglm wrote:
probably the cleanest way would be to create two seperate types for mapping java.sql.Timestamps and java.util.Dates - don't know, really


That's what I propose: creating a DateTime type that can be used in addition to the already existing ones. Since it doesn't exist yet - you won't break any existing code ;-)

This DateTime would behave the same way as the TimestampType except that its get() method would convert the timestamp retrieved from the resultset back into a java.util.Date...


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 1:42 pm 
Hibernate Team
Hibernate Team

Joined: Tue Sep 09, 2003 2:10 pm
Posts: 3246
Location: Passau, Germany
I have put this to JIRA at HB-681 to keep it and have gavin find a nice solution to this :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 1:54 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
Negative. The current solution is perfect.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2004 1:57 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
Note that no self-respecting code should EVER call equals on a Timestamp. Its almost as bad as for Float.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.