Description
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.
Attachments
Attachments
Issue Links
- is related to
-
OPENJPA-2755 support MySQL DATETIME and TIMESTAMP fractions (milliseconds, nanos)
- Resolved
- relates to
-
OPENJPA-638 Timestamp unsuitable for versioning on PostgreSQL databases
- Open
-
OPENJPA-2476 OptimisticLockEx due to rounding of a Timestamp (either by OJ, or the DB)
- Closed