openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: Quick question re date, time, timestamp or java.util.Date/Calendar
Date Fri, 06 Mar 2009 00:21:25 GMT
Hi Craig,

thanks for shedding some light on the issue.

It did seem like a severe omission since Dates and Calendars can't do nanoseconds.


Craig L Russell on 05/03/09 15:33, wrote:
> Hi Adam,
> I think there is a misunderstanding. From the spec, 2.2:
> The persistent fields or properties of an entity may be of the following 
> types: Java primitive types;
> java.lang.String; other Java serializable types (including wrappers of 
> the primitive types,
> java.math.BigInteger, java.math.BigDecimal, java.util.Date,
> java.util.Calendar[5], java.sql.Date, java.sql.Time, java.sql.Timestamp,
> byte[], Byte[], char[], Character[], and user-defined types that 
> implement the Serial-
> izable interface); enums; entity types; collections of entity types; 
> embeddable classes (see Section
> 2.5); collections of basic and embeddable types (see Section 2.6).
> So there is no problem using a java.sql Time, Date, or Timestamp as a 
> persistent field or property type.
> The @Temporal annotation was introduced so the provider would be able to 
> figure out the correct methods to persist java.util.Date and 
> java.util.Calendar, since these have no standard representation in the 
> database.
> Your code might work if you simply omit the @Temporal annotation entirely.
> Craig
> On Mar 5, 2009, at 4:39 AM, Adam Hardy wrote:
>> Actually the JPA spec (1.0 and 2.0) has a knock-on effect concerning 
>> the use of entity beans in the front-end.
>> Since I must use either java.util.Date or Calendar as the type for my 
>> temporal properties, I can't rely on the property type to distinguish 
>> between times and dates when it comes to displaying the values or for 
>> parsing incoming HTTP parameters.
>> This gives the programmer extra coding burden in the front-end, and I 
>> can't see any counter-balancing advantage in the persistence layer 
>> from banning the use of java.sql.Date and Time.
>> Have I missed something or is this an improvement that should be put 
>> into JPA 2 before it goes final?
>> Adam Hardy on 04/03/09 23:54, wrote:
>>> Thanks Mike.
>>> Looks like the same wording in JPA 2.0 too.
>>> Regards Adam
>>> Michael Dick on 04/03/09 19:39, wrote:
>>>> Hi Adam,
>>>> Looks like we're less stringent about the @Temporal annotation. I'd 
>>>> have to
>>>> look closer to see that's the case.
>>>> Regarding the JPA 2.0 spec you can find a copy of the public review 
>>>> draft here 
>>>> -mike
>>>> On Wed, Mar 4, 2009 at 10:57 AM, Adam Hardy 
>>>> <>wrote:
>>>>> I converted my project over from java.util.Date to 
>>>>> java.sql.Timestamp for
>>>>> entity fields after I figured that would give me more room to maneuver
>>>>> with a new requirement for time fields.
>>>>> It went smoothly with OpenJPA and made the MVC layer's type 
>>>>> converter code a cinch to refactor.
>>>>> However I then ran my tests under Hibernate JPA and Toplink 
>>>>> Essentials,
>>>>> and both complained bitterly that I was violating the spec and 
>>>>> threw exceptions.
>>>>> Looking through the JPA 1 spec, I see where I have transgressed 
>>>>> (9.1.20):
>>>>> "The Temporal annotation must be specified for persistent fields or 
>>>>> properties of type java.util.Date and java.util.Calendar. It may 
>>>>> only be specified for fields or properties of these types."
>>>>> Is the OpenJPA interpretations deliberately including Timestamp or 
>>>>> is that considered an OpenJPA feature?
>>>>> Is there any change in JPA 2?
>>>>> Also, can anyone give a URL for the JPA 2 spec pdf? Google turned 
>>>>> up nothing.
> Craig L Russell
> Architect, Sun Java Enterprise System
> 408 276-5638
> P.S. A good JDO? O, Gasp!

View raw message