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?
On Thu, May 4, 2017 at 12:26 PM Lukas Jungmann <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
>
>
>