users@jpa-spec.java.net

[jpa-spec users] Re: JPA_SPEC-63

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Thu, 04 May 2017 11:55:44 -0700

Hi Steve,

On 5/4/17, 11:45 AM, Steve Ebersole wrote:
> Thanks Linda, understandable. Mapping zoned/offset types is a tricky
> subject overall, hence my objection to forcing providers to respect the
> with or without variant of these database types.
>
> A perfectly acceptable and widely used approach to storing dates and
> times into the database is to convert all values to UTC, and hence
> storing the TZ is rendundant. I don't think the approach a particular
> vendor chooses for timezone handling ought to be limited here. In my
> opinion there should be wording in these additions in the second
> paragraph under "11.1.6 Basic Annotation" stating that providers are
> allowed to map values to use the non-WITH_TIMEZONE variants.
>

I think the language below already allows you that option.

>
> On Thu, May 4, 2017 at 1:13 PM Linda DeMichiel
> <linda.demichiel_at_oracle.com <mailto:linda.demichiel_at_oracle.com>> wrote:
>
>
>
> On 5/4/17, 10:59 AM, Steve Ebersole wrote:
> > So long as we are not requiring providers to
> > chose TIMESTAMP_WITH_TIMEZONE/TIME_WITH_TIMEZONE as the mapping
> > for java.time.OffsetDatetime/java.time.OffsetTime then that text
> looks
> > good to me. Also, why no support for java.time.Zoned* variants?
> >
>
> Since this is only an MR, we wanted to provide something
> straightforward and simple enough to accommodate in the
> time frame that we have -- hence the restrictions to time
> types directly supported by JDBC.
>
> >
> > On Thu, May 4, 2017 at 12:26 PM Lukas Jungmann
> > <lukas.jungmann_at_oracle.com <mailto:lukas.jungmann_at_oracle.com>
> <mailto:lukas.jungmann_at_oracle.com
> <mailto:lukas.jungmann_at_oracle.com>>> wrote:
> >
> > Hi,
> >
> > for this, I think adding java.time.LocalDate,
> > java.time.LocalTime, java.time.LocalDateTime,
> java.time.OffsetTime
> > and java.time.OffsetDateTime can be acceptable and doable
> from JPA
> > MR perspective so it is on par with others such as JDBC. That
> means
> > following additions (in italics) to the spec, which I'd like
> to propose:
> >
> >
> > *2.2 Persistent Fields and Properties*
> > ...
> > 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[], /java.time.LocalDate,
> > java.time.LocalTime, java.time.LocalDateTime,
> > java.time.OffsetTime, java.time.OffsetDateTime,/ and user-defined
> > types that implement the Serializable
> > interface); enums; entity types; collections of entity types;
> > embeddable classes (see Section
> > 2.5); collections of basic and embeddable types (see Section
> 2.6).
> > …
> >
> >
> > *2.8 Mapping Defaults for Non-Relationship Fields or Properties*
> >
> > …
> > If the type of the field or property is one of the following,
> it is
> > mapped in the same way as it
> > would if it were annotated as Basic: Java primitive types,
> wrappers
> > of the primitive types,
> > java.lang.String, java.math.BigInteger, java.math.BigDecimal,
> > java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time,
> > java.sql.Timestamp, /java.time.LocalDate, java.time.LocalTime,
> > java.time.LocalDateTime, java.time.OffsetTime,
> > java.time.OffsetDateTime,/
> > byte[], Byte[], char[], Character[], enums, any other
> > type that implements Serializable. See Sections 11.1.6, 11.1.18,
> > 11.1.28, and 11.1.51.
> > …
> >
> >
> > *11.1.6 Basic Annotation*
> >
> > The Basic annotation is the simplest type of mapping to a
> database
> > column. The Basic annotation
> > can be applied to a persistent property or instance variable
> of any
> > of the following types: Java primitive
> > types, wrappers of the primitive types, java.lang.String,
> > java.math.BigInteger,
> > java.math.BigDecimal, java.util.Date, java.util.Calendar,
> java.sql.Date,
> > java.sql.Time, java.sql.Timestamp, /java.time.LocalDate,
> > java.time.LocalTime,//
> > //java.time.LocalDateTime, java.time.OffsetTime,
> > java.time.OffsetDateTime,/ byte[], Byte[], char[], Character[],
> > enums, and any other type that implements Serializable. As
> described
> > in Section 2.8, the use of
> > the Basic annotation is optional for persistent fields and
> > properties of these types. If the Basic annotation
> > is not specified for such a field or property, the default
> values of
> > the Basic annotation will apply.
> >
> > /Mapping of java.time.LocalDate, java.time.LocalTime,
> > java.time.LocalDateTime, java.time.OffsetTime
> > and java.time.OffsetDateTime types////to columns other than those
> > supported by the mappings defined by//
> > //Appendix B of the JDBC 4.2 specification is not required to
> > be////supported by the persistence provider
> > beyond the support required////for other serializable types./
> >
> > *
> > *
> >
> > *13. * *Related Documents*
> >
> > ...
> > [ 5 ] /JDBC 4.2 Specification./
> http://jcp.org/en/jsr/detail?id=221.
> > ...
> >
> > WDYT?
> >
> > Thank you,
> > --lukas
> >
> >
> > On 5/2/17 1:42 PM, Werner Keil wrote:
> >> I admit, it probably exceeds a simple MR, but since at least
> Bean
> >> Validation 2 adds java.time support for Java EE 8 I wonder, if
> >> https://java.net/jira/browse/JPA_SPEC-63 was addressable or not
> >> for EE 8?
> >>
> >> I am also aware of the gross incompatibility of e.g.
> java.sql.Time
> >> etc. and the types in java.time all of which are final, so
> it does
> >> not look like the underlying JDBC in 4.2 or beyond is able to
> >> support all of it, but could e.g. TemporalType get further
> >> variations including "LOCAL_DATE_TIME", "INSTANT" or whatever
> >> seems appropriate?
> >>
> >> Werner
> >
>