[
https://issues.apache.org/jira/browse/OPENJPA-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140096#comment-18140096
]
ASF subversion and git services commented on OPENJPA-3028:
----------------------------------------------------------
Commit 5d2c0d3e1856f5fe2c1f092df1d82b327f91dec2 in openjpa's branch
refs/heads/master from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=5d2c0d3e1 ]
[OPENJPA-3028] Bind DATE values without their time of day (#280)
* [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.
* [OPENJPA-3028] Bind times at the precision of DATE columns on Oracle
Times are mapped to DATE columns on Oracle, which drop the fraction of
the second when a value is stored. A LocalTime or OffsetTime parameter
with a fraction of a second was bound with it and so never equalled the
value stored for the same time. A time bound for a DATE column is now
bound without the fraction; columns that can hold it, such as TIMESTAMP
columns, 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)
