[
https://issues.apache.org/jira/browse/OPENJPA-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139648#comment-18139648
]
ASF subversion and git services commented on OPENJPA-3028:
----------------------------------------------------------
Commit 5b9d695273b2fb0b615b93c5fb2c123d222bb773 in openjpa's branch
refs/heads/OPENJPA-3028-oracle-temporal from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=5b9d69527 ]
[OPENJPA-3028] Bind DATE values without their time of day
A java.util.Date or Calendar bound for a DATE column, as the value of a
@Temporal(DATE) attribute or as a parameter, and a parameter set with
TemporalType.DATE were converted with new java.sql.Date(millis), which
keeps the time of day, although a java.sql.Date has to be normalized to
the start of its day. A java.sql.Date holding a time of day was bound
as it was. Most drivers drop the time when binding a date, but the
Oracle driver stores and compares it as part of the DATE value, so a
date attribute or parameter holding a time of day never equalled a
stored date.
Every date bound for a DATE column, or as a parameter without a known
column, whether it is a java.util.Date, a Calendar or a java.sql.Date,
is now bound as the java.sql.Date of its day in the default time zone,
so that the same value binds the same way in an INSERT, in a query
parameter and in a primary key lookup. A java.sql.Date bound with an
explicit Calendar, and a java.sql.Date attribute mapped to a column
that is not of type DATE, are bound as before.
Behaviour change on Oracle: the time of day of a date attribute mapped
to a DATE column (a java.sql.Date, or a java.util.Date or Calendar with
@Temporal(DATE)) is no longer stored, and such values and
TemporalType.DATE parameters are bound as midnight. The time of day of
the value held by the entity in memory is unchanged. Rows written by
earlier versions keep the time of day they were stored with, and no
longer compare equal to the same value bound now: a query on such a
column, em.find on such an id, or an update or delete of a row keyed
by such a column does not find the row. Normalize those columns, for
example with UPDATE <table> SET <column> = TRUNC(<column>), before
upgrading. Databases whose DATE type has no time of day are not
affected.
> Jakarta Persistence 3.2 TCK failures on Derby, MySQL and SQL Server
> -------------------------------------------------------------------
>
> Key: OPENJPA-3028
> URL: https://issues.apache.org/jira/browse/OPENJPA-3028
> Project: OpenJPA
> Issue Type: Epic
> Reporter: Richard Zowalla
> Assignee: Richard Zowalla
> Priority: Major
> Attachments: run_de.tar.xz, run_ms.tar.xz, run_my.tar.xz,
> run_or.tar.xz
>
>
> Results of the Jakarta Persistence 3.2 TCK with
> {{openjpa-integration/tck/run-tck32.sh}} (reported by Maxim Solodovnik on
> dev@):
> * PostgreSQL 16: passed
> * MySQL 8.4.8: 2134 tests, 43 errors
> * SQL Server 2017-CU12: 2134 tests, 45 errors
> * Derby: 2134 tests, 184 errors
> The sub-tasks group the errors by cause. Several groups show up on more than
> one database. Where the TCK output only says "<test> failed", the cause still
> has to be found from the TCK logs.
> Note: the TCK build does not work with Maven 3.10.0; 3.9.x works.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
