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
<[email protected]>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:[email protected]
P.S. A good JDO? O, Gasp!
