[
https://issues.apache.org/jira/browse/OPENJPA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672140#comment-16672140
]
ASF subversion and git services commented on OPENJPA-2555:
----------------------------------------------------------
Commit 9461ffdfcd870b1aeadf1eab3e8181c983a595b4 in openjpa's branch
refs/heads/master from [~struberg]
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=9461ffd ]
OPENJPA-2775 OPENJPA-2555 fraction of seconds in MySQL
This is a first fix for supporting fractions of a second in MySQL.
> 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
> 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
(v7.6.3#76005)
