[
https://issues.apache.org/jira/browse/OPENJPA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679130#comment-16679130
]
Ancoron Luciferis commented on OPENJPA-2555:
--------------------------------------------
Sorry for re-opening, but after evaluating and also implementing this for
PostgreSQL, I've seen that the default behavior (no {{scale}} provided) now
changes, which might conflict with users' expectations especially when
upgrading OpenJPA for a DBMS we haven't tested for this, yet.
Therefore, I've refactored the core change and reverted the default behavior to
not apply or assume any decimal digits:
* [^timestamp-scale-preserve-default-behavior.patch]
\\
[~struberg]: please have a look at it.
> 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
> Assignee: Mark Struberg
> Priority: Major
> Fix For: 3.0.1
>
> 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,
> timestamp-scale-preserve-default-behavior.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
(v7.6.3#76005)
