[
https://issues.apache.org/jira/browse/OPENJPA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681165#comment-16681165
]
Mark Struberg commented on OPENJPA-2555:
----------------------------------------
Hi [~ancoron]!
I totally understand and support your position regarding backward compatibility
and production databases!
But in this very case we imo do have to make a trade off. Not having millis and
microseconds support in OpenJPA out of the box for those DBs is really weird
these days. I'm also _very_ picky on my data. In fact I strongly suggest to NOT
let any JPA provider touch your schemas in production. Usually my connections
also do *not* have any grants to create/drop/alter tables!
In production one should always only use manual updates or have systems like
liquibase do the schema adoption. All of this of course based on the schema
generated by OpenJPA. But please at build time and only after manual
verification of the SQLs - and not at runtime ;)
So in practice this should not have any effect on existing applications - and
new ones will be able to make use of the enhanced accuracy!
Btw, super cool that you help with PostgreSQL! I'm right now just fixing a few
other broken tests with Postgres. If those are green then I'll happily come
back to this very topic and helping you getting this feature down to the floor!
Just doing all this in my spare time, so please give me a few days - 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)
