July 2023 - hibernate-issues - Jboss List Archives

[JIRA] (HHH-16967) Missing join on inheritance parent table to validate @Where condition

by Mikaël Peoc'h (JIRA)

2 years, 5 months

1
0
0 / 0

[JIRA] (HHH-16967) Missing join on inheritance parent table to validate @Where condition

by Mikaël Peoc'h (JIRA)

Mikaël Peoc'h ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMjg2NjQ3ZTJm... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16967?atlOrigin=eyJpIjoiMjg2Nj... ) HHH-16967 ( https://hibernate.atlassian.net/browse/HHH-16967?atlOrigin=eyJpIjoiMjg2Nj... ) Missing join on inheritance parent table to validate @Where condition ( https://hibernate.atlassian.net/browse/HHH-16967?atlOrigin=eyJpIjoiMjg2Nj... ) Change By: Mikaël Peoc'h ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Since migrating to Spring Boot 3, I noticed some weird behaviour while using the @Where annotation acting as a soft delete in conjunction with the joined table inheritance pattern. The basic use case is: * child entity inheriting from a parent entity using the joined table pattern * The parent entity has a @Where annotation used for detecting a soft delete * the child entity has 2 {{OneToMany}} relations on primary and secondary objects When trying to get a primary object with a condition on a secondary object going through the child entity, the @Where condition is applied, but the SQL JOIN condition it produces isn’t valid Here is the SQL produced and the error: {quote}SELECT P1_0.ID, P1_0.CHILD_ID, P1_0.DATA FROM PRIMARYOBJECT P1_0 JOIN CHILD C1_0 ON C1_0.ID = P1_0.CHILD_ID AND (C1_1.DELETED_ON IS NULL) JOIN SECONDARYOBJECT S1_0 ON C1_0.ID = S1_0.CHILD_ID WHERE S1_0.DATA = ?{quote} {{ERROR SqlExceptionHelper:150 - Column "C1_1.DELETED_ON" not found}} Here is the PR to reproduce this behaviour : [https://github.com/hibernate/hibernate-test-case-templates/pull/ 297 300 |https://github.com/hibernate/hibernate-test-case-templates/pull/ 297 300 |smart-link] ( https://hibernate.atlassian.net/browse/HHH-16967#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16967#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#100233- sha1:f5b6255 )

2 years, 5 months

1
0
0 / 0

[JIRA] (HSEARCH-4403) Support ORM's discriminator-based multi-tenancy in the outbox-polling module

by Automation for Jira (JIRA)

2 years, 5 months

1
0
0 / 0

[JIRA] (HHH-16864) JPA Criteria queries do not conform to JPA spec when distinct=false

by Christian Beikov (JIRA)

2 years, 5 months

1
0
0 / 0

[JIRA] (HHH-16864) JPA Criteria queries do not conform to JPA spec when distinct=false

by Christian Beikov (JIRA)

Christian Beikov ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16864 ( https://hibernate.atlassian.net/browse/HHH-16864?atlOrigin=eyJpIjoiODRiNz... ) Re: JPA Criteria queries do not conform to JPA spec when distinct=false ( https://hibernate.atlassian.net/browse/HHH-16864?atlOrigin=eyJpIjoiODRiNz... ) >But could you please explain, how hibernate conforms to the following quote of the JPA spec? >Because I think it does not conform - I just do not get the possibility to use distinct(false) properly, even if I want to, for whatever reason. Conformance is determined by running the JPA TCK with the JPA provider as implementation, and ORM 6 passes that TCK. Calling distinct(false) has no impact as that is the default. What you are complaining about is the change in behavior that is documented in the migration guide ( https://github.com/hibernate/hibernate-orm/blob/6.0/migration-guide.adoc#... ). If you can give us a good use case for the behavior you seem to desire, we can talk about it, but until then, I’ll close this issue as doing this was a deliberate decision. ( https://hibernate.atlassian.net/browse/HHH-16864#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16864#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#100233- sha1:f5b6255 )

2 years, 5 months

1
0
0 / 0

[JIRA] (HHH-16986) CoercionException caused by attempted coercion of query param to entity field type

by Ruben Gehring (JIRA)

Ruben Gehring ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6401f5e... ) *commented* on HHH-16986 ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiYjM5OT... ) Re: CoercionException caused by attempted coercion of query param to entity field type ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiYjM5OT... ) Thank you for the explanation. 🙂 I had always assumed that surely Hibernate must know the java types of it’s parameters at the time hql types are decided, after all the hql produced usually matches the java type closely. I guess in reality it’s just really good at type guessing. But I can see how relying on any amount of type guessing is undesirable in terms of minimizing unexpected behavior. What would have helped me getting to the bottom of this earlier is an error message that expresses why hibernate even attempted the coercion in the first place. I initially thought that Hibernate was deriving the hql type from the java type of my parameter and for some reason my field’s java type was used to determine the parameter’s hql type whereas it should’ve been my parameter’s java type. See also the title of this issue 😄 In any case, I’ll be using the cast for my arithmetic operand parameters from now on. If Hibernate ever improves it’s automatic type inference so that the explicit casting is no longer required I’d be happy but doing it if and only if a good rule can be made seems quite reasonable. ( https://hibernate.atlassian.net/browse/HHH-16986#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16986#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#100233- sha1:f5b6255 )

2 years, 5 months

1
0
0 / 0

[JIRA] (HHH-16990) Add support for @Type @JdbcTypeCode @UuidGenerator to XML mapping

by Marko Bekhta (JIRA)

2 years, 5 months

1
0
0 / 0

[JIRA] (HHH-16939) Optimistic and Pessimistic Force Increment Update Statements are not committed when using a batch

by Andrea Boriero (JIRA)

2 years, 5 months

1
0
0 / 0

[JIRA] (HHH-16959) Fail to batch delete entities with nested embeddeds

by Andrea Boriero (JIRA)

2 years, 5 months

1
0
0 / 0

[JIRA] (HHH-16959) Fail to batch delete entities with nested embeddeds

by Andrea Boriero (JIRA)

2 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2023