openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Quick question re date, time, timestamp or java.util.Date/Calendar
Date Thu, 05 Mar 2009 15:33:32 GMT
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 http://jcp.org/aboutJava/communityprocess/pr/jsr317/index.html
>>> -mike
>>> On Wed, Mar 4, 2009 at 10:57 AM, Adam Hardy <adam.sql@cyberspaceroad.com 
>>> >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 http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message