Mike Becker (
https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6321cb8...
) *updated* an issue
Hibernate ORM (
https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMTczMmI5YWVh...
) / Bug (
https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiMTczMm...
) HHH-15548 (
https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiMTczMm...
) PostgreSQL: Hibernate creates column with "timestamp with timezone" and then
fails to validate it (
https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiMTczMm...
)
Change By: Mike Becker (
https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6321cb8...
)
h2. What was observed?
h3. Windows + PostgreSQL 10 or 14 Database / Linux + PostgreSQL 10 Database
Hibernate throws the following schema validation exception:
{quote}org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: wrong
column type encountered in column \[mycolumn] in table \[mytable]; found \[timestamptz
(Types#TIMESTAMP)], but expecting \[timestamp(6) with time zone
(Types#TIMESTAMP_UTC)]{quote}
The underlying Java datatype is java.util.Instant.
h2. Additional Information
In both databases the {{information_schema}} describes the column as
||data_type||datetime_precision||
|timestamp with time zone|6|
The column in the windows database was created with an DDL statement containing
{{timestamp(6) with time zone}} as datatype which was extracted from the linux database
which had been created by hibernate with {{hibernate.hbm2ddl.auto=create-drop}}.
Recent tests showed that the bug also occurs in the linux installation when the
application is redeployed. That means, hibernate is rejecting the datatype it created
before.
h2. What is the Bug?
Hibernate states that the “found” datatype would be literally {{timestamptz}}, although
postgres itself (via the {{information_schema}}) describes the datatype as {{timestamp
with time zone}}. Actually it should not matter, because {{timestamptz}} is just an alias
for {{timestamp with time zone}} but it is confusing where Hibernate gets the information
from, because it clearly cannot be what the information schema offers.
More precisely, the bug is that Hibernate _claims_ the data type would be {{timestamptz}}
although it
* has been created with {{timestamp(6) with timezone}}
* is described by IDEs (e.g. JetBrains Data Grip) as {{timestamp(6) with timezone}}
* is described by the information schema as {{timestamp with time zone}} with precision
{{6}}
* was actually created by hibernate with {{hibernate.hbm2ddl.auto=create-drop}}
So we can safely assume, that the datatype *is* actually {{timestamp(6) with timezone}}
and therefore, exactly what Hibernate is expecting in the exception text: {{expecting
[timestamp(6) with time zone (Types#TIMESTAMP_UTC)]}}
Even if hibernate somehow internally recognizes {{timestamp with timezone}} as
{{timestamptz}} (which imho is wrong, because Hibernate should use what the information
schema says and should not work with its own interpretations), then the data types would
still be the same, because {{timestamptz}} is just an alias.
(
https://hibernate.atlassian.net/browse/HHH-15548#add-comment?atlOrigin=ey...
) Add Comment (
https://hibernate.atlassian.net/browse/HHH-15548#add-comment?atlOrigin=ey...
)
Get Jira notifications on your phone! Download the Jira Cloud app for Android (
https://play.google.com/store/apps/details?id=com.atlassian.android.jira....
) or iOS (
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em...
) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100207- sha1:520255c )