[
https://issues.apache.org/jira/browse/OPENJPA-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138840#comment-18138840
]
ASF subversion and git services commented on OPENJPA-3034:
----------------------------------------------------------
Commit 2bbe31e0477369dafd82d2ce804b1f4530651f06 in openjpa's branch
refs/heads/OPENJPA-3034 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=2bbe31e04 ]
[OPENJPA-3034] Keep timestamp versions at the precision of the column
A timestamp version column of a schema not created by OpenJPA may keep
fewer fractional digits of a second than the dictionary assumes. The TCK
creates the version column of core.annotations.version.Client4 as a
MySQL/MariaDB TIMESTAMP without fractional seconds and as a SQL Server
DATETIME (1/300 s granularity). The version kept in memory (and bound in
the WHERE clause of the next UPDATE) then never matched the stored value,
and timestampFieldTest/timestampPropertyTest failed with an
OptimisticLockException.
TimestampVersionStrategy generates the versions at the precision of the
column when that is coarser than the dictionary's datePrecision. A
precision declared in the mapping, the JPA 3.2 @Column(secondPrecision),
is used as it is. Otherwise the precision is read from the database
metadata on the first insert or update, and if coarser recorded on the
column. The result is kept per column, so entities mapped to the same table
share one lookup and the same precision, and later flushes do not query the
metadata.
The lookup is skipped for dictionaries that need auto-commit for metadata
operations, as it would end the transaction.
DBDictionary.getTimestampPrecision(Column) maps a known column precision
(0-9 fractional digits) to the rounding granularity used by
setTimestamp(). SQLServerDictionary rounds to 10 ms for a DATETIME column,
the granularity that DATETIME stores exactly and that compares equal to
the DATETIME2 parameter the driver sends; other three digit columns such
as DATETIME2(3) keep whole milliseconds.
Column.copy() did not carry secondPrecision, so it never reached the
column of a @Version field (neither its DDL nor the version strategy);
it does now.
NanoPrecisionTimestampVersionStrategy now supplies the current time
through currentTimestamp() so that the rounding applies to it as well.
> Tests failing on several databases: sequence generator, timestamp, scalar
> expressions, mixed access
> ---------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-3034
> URL: https://issues.apache.org/jira/browse/OPENJPA-3034
> Project: OpenJPA
> Issue Type: Sub-task
> Reporter: Richard Zowalla
> Priority: Major
>
> These tests fail on more than one database, which suggests a common cause:
> * {{sequenceGeneratorTest}}: Derby, MySQL, SQL Server. Check with
> OPENJPA-3014 (named sequence generator backed by a table where there are no
> sequences).
> * {{Client4.timestampFieldTest}}, {{timestampPropertyTest}}: MySQL, SQL
> Server (fractional seconds?)
> * {{scalarExpressionsTest}} ({{Client}} and {{Client1}}): Derby, SQL Server
> * {{Client2.mixedAccessTest}}, {{Client3.transientTest}},
> {{Client2.transientTest}}: Derby, SQL Server
> * {{cascadeAllMX1Test2}}, {{persistMX1Test2}}: Derby, SQL Server
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
