[
https://issues.apache.org/jira/browse/OPENJPA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669387#comment-16669387
]
Mark Struberg commented on OPENJPA-2555:
----------------------------------------
I debugged through some very similar approach as you did. But I fear that the
{{@Column(scale = 3)}} trick doesn't work out.
The reason is that the default value for scale is 0 and not -1. So once you add
a {{@Column}} even just for the sake of defining the column name, then you end
up with scale = 0 and thus truncating all the second fractions.
We could probably only abuse the 'length' attribute of
javax.persistence.Column. This has default 255. Not as intuitive, but should
work. We are of course leaving any specified ground...
> 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)
