[
https://issues.apache.org/jira/browse/OPENJPA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679631#comment-16679631
]
Mark Struberg commented on OPENJPA-2555:
----------------------------------------
The default of no-scale only changes for databases where this is not the
default anyway.
The {{DBDictionary#timestampTypeName}} right now only gets changed in
{{MySQLDictionary#205}}. The additional condition in
{{DBDictionary#appendSize}} is depending on an entry in
{{DBDictionary#fractionalTypeNameSet}} which again only gets set in
{{MySQLDictionary}}. Of course the default for MySQL will now be
{{DATETIME(6)}}. But this is also what is perfectly reasonable and portable
with the behaviour of OpenJPA in other databases.
Note that it will not have any effect on existing databases as the Metadata
merge should take precedence.
Did I miss something?
I did not yet touch any other database. PostgreSQL is currently in work. I've
already added the -Ptest-postgresql-docker profile if you would like to take a
look, which would be great! txs!
> 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)
