[JIRA] (HHH-15548) PostgreSQL: Hibernate claims to have found "timestamptz" and also claims that it is incompatible with "timestamp with timezone"
by Mike Becker (JIRA)
Mike Becker ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6321cb8... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiODZjODZmYmVh... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiODZjOD... ) HHH-15548 ( https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiODZjOD... ) PostgreSQL: Hibernate claims to have found "timestamptz" and also claims that it is incompatible with "timestamp with timezone" ( https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiODZjOD... )
Change By: Mike Becker ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6321cb8... )
h2. What was observed?
h3. Windows + PostgreSQL 14 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.
h3. Linux + PostgreSQL 10 Database
The exception is not thrown.
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}}.
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}}
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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100207- sha1:1c92a42 )
2 years
[JIRA] (HSEARCH-4706) Fix flaky test on DB2
by Yoann Rodière (JIRA)
Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue
Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiNTc3ZmNi... ) / Task ( https://hibernate.atlassian.net/browse/HSEARCH-4706?atlOrigin=eyJpIjoiNTc... ) HSEARCH-4706 ( https://hibernate.atlassian.net/browse/HSEARCH-4706?atlOrigin=eyJpIjoiNTc... ) Fix flaky test on DB2 ( https://hibernate.atlassian.net/browse/HSEARCH-4706?atlOrigin=eyJpIjoiNTc... )
Issue Type: Task Assignee: Unassigned Components: tests Created: 26/Sep/2022 03:25 AM Fix Versions: 6.2-backlog Priority: Major Reporter: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... )
https://ci.hibernate.org/job/hibernate-search/job/main/482/testReport/jun... ( https://ci.hibernate.org/job/hibernate-search/job/main/482/testReport/jun... )
org.opentest4j.AssertionFailedError:
[Count of indexing operations across all session factories for tenant ID <null>]
expected: 3
but was: 4
at jdk.internal.reflect.GeneratedConstructorAccessor216.newInstance(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at org.hibernate.search.integrationtest.mapper.orm.coordination.outboxpolling.automaticindexing.OutboxPollingAutomaticIndexingShardingBaseIT.uniqueWorkAcrossSessionFactories_insertUpdateDelete_contained(OutboxPollingAutomaticIndexingShardingBaseIT.java:192)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.hibernate.search.util.impl.integrationtest.common.rule.BackendMock$1.evaluate(BackendMock.java:52)
at org.hibernate.search.util.impl.test.rule.StaticCounters$1.evaluate(StaticCounters.java:63)
at org.hibernate.search.util.impl.integrationtest.common.rule.MappingSetupHelper$1.evaluate(MappingSetupHelper.java:74)
at org.hibernate.search.util.impl.integrationtest.common.TestConfigurationProvider$1.evaluate(TestConfigurationProvider.java:45)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
( https://hibernate.atlassian.net/browse/HSEARCH-4706#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-4706#add-comment?atlOrigin... )
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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100207- sha1:1c92a42 )
2 years
[JIRA] (HHH-15548) PostgreSQL: Hibernate claims to have found "timestamptz" and also claims that it is incompatible with "timestamp with timezone"
by Mike Becker (JIRA)
Mike Becker ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6321cb8... ) *created* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiN2NjZjdmMTFm... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiN2NjZj... ) HHH-15548 ( https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiN2NjZj... ) PostgreSQL: Hibernate claims to have found "timestamptz" and also claims that it is incompatible with "timestamp with timezone" ( https://hibernate.atlassian.net/browse/HHH-15548?atlOrigin=eyJpIjoiN2NjZj... )
Issue Type: Bug Affects Versions: 6.1.3 Assignee: Unassigned Components: hibernate-core Created: 26/Sep/2022 03:09 AM Priority: Major Reporter: Mike Becker ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6321cb8... )
------------------
What was observed?
------------------
Windows + PostgreSQL 14 Database
--------------------------------
Hibernate throws the following schema validation exception:
>
>
>
> 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)]
>
>
The underlying Java datatype is java.util.Instant.
Linux + PostgreSQL 10 Database
------------------------------
The exception is not thrown.
----------------------
Additional Information
----------------------
In both databases the information_schema describes the column as
data_type datetime_precision timestamp with time zone 6
The column was created with an DDL statement containing timestamp(6) with time zone as datatype.
----------------
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
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) ( #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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100207- sha1:1c92a42 )
2 years
[JIRA] (HHH-15545) @NotFound(Ignore) defaults to eager loading
by Gavin King (JIRA)
Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-15545 ( https://hibernate.atlassian.net/browse/HHH-15545?atlOrigin=eyJpIjoiZTk0ZD... )
Re: @NotFound(Ignore) defaults to eager loading ( https://hibernate.atlassian.net/browse/HHH-15545?atlOrigin=eyJpIjoiZTk0ZD... )
So I dunno, the situation here is pretty weird. There actually is one test that looks superficially like it exercises @NotFound on a collection, but it’s pretty weird case with a @OneToMany. (I really don’t see how @NotFound could possibly make sense for @OneToMany.)
The test is JoinFormulaOneToManyNotIgnoreLazyFetchingTest which, despite its name, has nothing to of with @JoinFormula. And I can make this test pass just by using @OneToMany(fetch = FetchType.EAGER) instead of @NotFound , so it doesn’t look like a legit test for @NotFound at all! So, AFAICT, this test is just bogus, and should never have been pushed.
The referenced issue in the test is https://hibernate.atlassian.net/browse/HHH-12770 ( https://hibernate.atlassian.net/browse/HHH-12770 ) , and it looks like it was written by a user and pushed by Vlad as part of this PR: https://github.com/hibernate/hibernate-orm/pull/2459 ( https://github.com/hibernate/hibernate-orm/pull/2459 ).
Apart from that bogus-looking test, there’s no test for @NotFound on a collection.
( https://hibernate.atlassian.net/browse/HHH-15545#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-15545#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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100207- sha1:1c92a42 )
2 years