You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Adam Hardy <ad...@cyberspaceroad.com> on 2009/03/04 17:57:22 UTC
Quick question re date, time, timestamp or java.util.Date/Calendar
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.
Thanks
Adam
Re: Quick question re date, time, timestamp or java.util.Date/Calendar
Posted by Adam Hardy <ad...@cyberspaceroad.com>.
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.
Regards
Adam
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
>>>> http://jcp.org/aboutJava/communityprocess/pr/jsr317/index.html
>>>> -mike
>>>> On Wed, Mar 4, 2009 at 10:57 AM, Adam Hardy
>>>> <ad...@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!
>
Re: Quick question re date, time, timestamp or java.util.Date/Calendar
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: Quick question re date, time, timestamp or java.util.Date/Calendar
Posted by Adam Hardy <ad...@cyberspaceroad.com>.
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
>> <ad...@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.
Re: Quick question re date, time, timestamp or java.util.Date/Calendar
Posted by Adam Hardy <ad...@cyberspaceroad.com>.
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 <ad...@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.
>>
>>
>> Thanks
>> Adam
>>
>
Re: Quick question re date, time, timestamp or java.util.Date/Calendar
Posted by Michael Dick <mi...@gmail.com>.
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 <ad...@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.
>
>
> Thanks
> Adam
>