[ 
https://issues.apache.org/jira/browse/OPENJPA-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139477#comment-18139477
 ] 

ASF subversion and git services commented on OPENJPA-3028:
----------------------------------------------------------

Commit 24795ec9cc7e965ac01ad13dbccbc3f73e2cebf9 in openjpa's branch 
refs/heads/master from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=24795ec9c ]

[OPENJPA-3066] Honour TemporalType in setParameter(Parameter, Calendar, 
TemporalType) (#272)

* [OPENJPA-3028] Honour TemporalType in setParameter(Parameter, Calendar, 
TemporalType)

The Calendar was converted to java.sql.Date/Time/Timestamp and then wrapped
back into a Calendar, so the temporal type was lost. A DATE parameter was
bound with the full time of day as soon as the query ran from the prepared
query cache, which binds parameters without their column.

Keep the Calendar as the value bound to the Parameter<Calendar>, so that
getParameterValue() still returns the caller's Calendar, and remember the
temporal type. The Calendar is converted to the temporal type when the
parameter values are handed to the query for execution, like the int and
String variants do at bind time. Rebinding the parameter without a
temporal type drops it again.

QueryResultCache.pin/unpin/evict(Query) build their cache key from the
values the query is executed with, so they still find the result of a
query whose Calendar parameter is converted to its temporal type.

Fixes TCK 
core.query.apitests.Client1#setParameterParameterCalendarTemporalTypeTest
on MySQL, MariaDB and SQL Server, where a DATE column never equals a DATETIME.

* [OPENJPA-3066] Use pattern matching and braces when building the query cache 
key

> 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)

Reply via email to