[
https://issues.apache.org/jira/browse/OPENJPA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ancoron Luciferis updated OPENJPA-2555:
---------------------------------------
Attachment: trunk-Enable-timestamp-precision-handling.patch
2.3.x-Enable-timestamp-precision-handling.patch
2.2.x-Enable-timestamp-precision-handling.patch
Attached a bunch of patches:
* For branch 2.2.x: [^2.2.x-Enable-timestamp-precision-handling.patch]
* For branch 2.3.x: [^2.3.x-Enable-timestamp-precision-handling.patch]
* For trunk: [^trunk-Enable-timestamp-precision-handling.patch]
\\
Those patches do the following:
* extend {{TimeKeeper}} test entity with 7 new members:
** each new member defined as {{java.sql.Timestamp}}
** each new member contains a timestamp precision using the JPA
{{\@javax.persistence.Column(scale = X)}}, where _X_ is defined from "0" to "6"
to test all precision arguments up to microseconds
* extend {{TestTemporalTypeQueryParameterBinding}} to test insertion, retrieval
and querying those new members
* extend {{DBDictionary}}:
** modify {{setTimestamp()}} to prefer column-specific precision if available
** add a new type set to register precision-only data types (no "size") like
for timestamp or time
** modify {{appendSize()}} to pick up on registered precision-only data types
(so we do not collide with current behavior for unmodified dictionaries) to get
precision into generated DDL
* extend {{MySQLDictionary}} to check for server version 5.6.4 or higher, which
brings in support for fractional seconds for timestamp, datetime and time data
types (see http://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html)
* change {{MySQLDictionary::datePrecision}} to seconds (= no fractional
seconds), because MySQL defaults to a precision of "0" when not defined
* extend {{PostgresDictionary}} to include precision support for data types
bit, time and timestamp
> 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
> Fix For: 2.2.3, 2.3.1, 2.4.0
>
> Attachments: 2.2.x-Enable-timestamp-precision-handling.patch,
> 2.3.x-Enable-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
(v6.3.4#6332)
