I want to make an application that has a date data type.
For the POJO, what is the ideal data type for date object?
Should I use String and let Hibernate do the rest of it? Since some people say that java.util.Date is not sufficient.

I'm going to use MySQL and the field is using date.

Thnx in advance.

IMO, java.util.Date is the only appropriate type to use in a domain model. However, if it is part of a key (bad idea) or you want to check equality to another date, .equals() may cause you problems. There are lots of issues with the Date hierarchy in java, and they are more related to the design of Java than to hibernate.

See
http://forum.hibernate.org/viewtopic.php?t=925275
http://forum.hibernate.org/viewtopic.php?t=927602

Well I've asked several people and they said that using java.util.Date is a bad idea since not every DBMS has the same date data type. And what about java.sql.Date, would it be much better?

Thnx for your input :)

To quote Gavin,



There are two downsides to not using a java.sql.Timestamp, in my opinion (note, I talk about Timestamp, here but there are similar considerations for java.sql.Date and java.sql.Time):
- there is a rare possibility of losing the nanosecond portion of the time if you load a date from the database, copy the value in that date to a java.util.Date object (that is, a java.util.Date that is not a java.sql.Timestamp), and then re-persist it to the database. As far as the database is concerned, there may be a slight difference in times.
- java.sql.Timestamp.equals(java.util.Date) always returns false if the java.util.Date is not a java.sql.Timestamp being treated as a date. It is a very subtle but important thing to understand when considering date equality.

That said, there are few good cases where you should ever be using equality comparisons on dates as a conditional and unless you are doing some sort of realtime system, who cares about a few nanoseconds difference? For most applications, using java.util.Date in the model is completely acceptable.

I feel Gavin's point is much more important in this argument, though: java.sql.Date/Timestamp/Time are JDBC persistence related object types. A more extreme form of the usual argument for java.sql.Timestamp would be:

Well, the database stores strings as an array of bytes, so I should make my firstName property of type byte[], right?

Now, with all of that said, it eventually comes down to a matter of taste. If you choose to use java.sql.Timestamp, fine. But you should probably (as is said in Hibernate in Action) be consistent, no matter which path you choose and use whichever you choose throughout your model.

I hope I've summarized most of the issues here, but the mentioned threads do a much better job of getting into the details of the matter. I wonder if anyone would be interested in writing an entry in the FAQs about this? I would offer to, but I'm not sure I have a good grasp of all the subtleties.

Is there a solution to convert a String type inputs from form submission into Date type?

have a look at java.util.GregorianCalendar After you created a instance call the .getTime method and you have your Date objet.

Hi

You could use SimpleDateFormat to change the format and all stuffs. I have using it quite a long time. If you want a sample let me know?

Thanks for the clue guys. But now I have another problems regarding date issue.

I get this message:


My Object type is java.util.Date


And this is what I wrote in the mapping file:


Could anyone give me a hint why does error occured?

Thanks in advance

If you have dates like "0000-00-00" in your database, and you can't change that (i.e. legacy data), you're going to want to use a custom UserType to handle this case.

What you mean is that "0000-00-00" is a null date. However, if you feed that into a SimpleDateFormat, it's going to give you a real date in return, and it won't be what you expect it to be. It's not null, because that date (however malformed it may be) actually exists.

You want a UserType that will interpret that string to mean "null" and save nulls as that string.

Thanks for the hint. I've got it covered now ;)

I don't see how a custom user type would solve this problem since the error is occuring in JDBC. Doesn't this happen before the custom user type can do anything to mitigate it?