[
https://issues.apache.org/jira/browse/OPENJPA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ancoron Luciferis updated OPENJPA-2555:
---------------------------------------
Attachment: openjpa-trunk-Enhance-timestamp-precision-handling.patch
openjpa-2.3.x-Enhance-timestamp-precision-handling.patch
openjpa-2.2.x-Enhance-timestamp-precision-handling.patch
Attached a new set of patches:
* For branch 2.2.x: [^openjpa-2.2.x-Enhance-timestamp-precision-handling.patch]
* For branch 2.3.x: [^openjpa-2.3.x-Enhance-timestamp-precision-handling.patch]
* For trunk: [^openjpa-trunk-Enhance-timestamp-precision-handling.patch]
\\
With these new patches I've now also done the following:
# Handle MySQL timestamp precision declaration (it requires a precision to be
specified), which means that if no JPA {{\@Column(scale = N)}} is specified,
the default precision being generated in the create table statement will be "6"
for MySQL server 5.6.4+
# As MySQL before version 5.6.4 does not support *any* timestamp precision,
I've explicitly disabled precision by changing the
{{DBDictionary#datePrecision}} field to {{SEC}} (always rounded to seconds)
# Refactored the change introduced by OPENJPA-2476 (introducing JDBC-only logic
into the kernel doesn't made any sense to me) and split the logic:
#* timestamp rounding logic went into the {{TimestampHelper}} inside Maven
project "openjpa-lib"
#* version column handling is now done by {{TimestampVersionStrategy}} inside
Maven project "openjpa-jdbc"
# Modified test {{TestTimestampOptLockEx}} to also run on PostgreSQL and MySQL
(also account for MySQL version < 5.6.4)
# Introduced test {{TestTimestampOptLockEx2}} which basically is the same test
as before, but using a different entity with timestamp precision specified
using {{\@Column(scale = 4)}} to make sure that non-millisecond rounding is
correct
> Timestamp precision from manual schema not respected
> ----------------------------------------------------
>
> Key: OPENJPA-2555
> URL: https://issues.apache.org/jira/browse/OPENJPA-2555
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, jpa, sql
> Affects Versions: 2.2.2, 2.3.0
> Reporter: Ancoron Luciferis
> Fix For: 2.2.3, 2.3.1, 2.4.0
>
> Attachments: 2.2.x-Enable-timestamp-precision-handling.patch,
> 2.3.x-Enable-timestamp-precision-handling.patch,
> openjpa-2.2.x-Enhance-timestamp-precision-handling.patch,
> openjpa-2.3.x-Enhance-timestamp-precision-handling.patch,
> openjpa-trunk-Enhance-timestamp-precision-handling.patch,
> trunk-Enable-timestamp-precision-handling.patch
>
>
> The use cases here are the following:
> # JPA entities are to-be-created for an existing database schema which
> includes several timestamp columns with explicit precision
> # A developer wants to specify timestamp precision inside JPA entities to
> better specify column data type information for the generated schema
> \\
> In both cases, the result will be that any query executed for a timestamp
> column that is configured for less than millisecond precision (e.g. deci- or
> centi-seconds) will fail to find appropriate rows.
> One of the reasons for that is that the precision used for rounding a
> timestamp value before it goes into a query is configured for a whole
> database type (using the dictionary) or the whole persistence context (using
> the configuration parameter).
> This makes it impossible to have different column configurations, e.g. some
> without any precision declaration (where it's not important) but some with.
> In addition, the default precision for the standard timestamp data type is 6
> (microseconds), which is not respected by some databases (most prominently
> MySQL, which defaults to a precision of "0" instead).
> However, even if respected, when using timestamps generated by the database
> itself, which include the relevant precision, using those values for later
> comparison often fails because of precision mismatch and also for different
> behavior of different databases regarding fractional handling and the way how
> comparisons on timestamps work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
