April 2023 - hibernate-issues - Jboss List Archives

[JIRA] (HHH-16451) Native query and @NotFound do not fetch the related entities

by Marco Belladelli (JIRA)

3 years

1
0
0 / 0

[JIRA] (HHH-16394) Statement Batch + Version + Dirty Collection leads to OptimisticLockException: Batch update returned unexpected row count from update

by Andrea Boriero (JIRA)

3 years

1
0
0 / 0

[JIRA] (HHH-16458) JDBC statement is not closed when DeferredResultSetAccess fails to execute a query

by Yoann Rodière (JIRA)

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiYWY0YzIyYTAy... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16458?atlOrigin=eyJpIjoiYWY0Yz... ) HHH-16458 ( https://hibernate.atlassian.net/browse/HHH-16458?atlOrigin=eyJpIjoiYWY0Yz... ) JDBC statement is not closed when DeferredResultSetAccess fails to execute a query ( https://hibernate.atlassian.net/browse/HHH-16458?atlOrigin=eyJpIjoiYWY0Yz... ) Issue Type: Bug Assignee: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Components: hibernate-core Created: 12/Apr/2023 00:54 AM Fix Versions: 6.2.1 Priority: Major Reporter: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) In org.hibernate.sql.exec.internal.JdbcSelectExecutorStandardImpl#doExecuteQuery , DeferredResultSetAccess (and thus the underlying JDBC statement) does not get released when resolveJdbcValuesSource throws an exception. In practice this is not a big issue as the JDBC driver or connection pool (e.g. Agroal) will likely close statements on connection release, but it does lead to annoying warnings with Agroal in particular. The leak can be reproduced for example by trying to execute specific queries in transactions: * a query with parameters whose type don’t match the SQL, e.g. SELECT ( :param / 2 ) with param = "foo" * with the MySQL JDBC driver, a query referencing tables that don’t exist (this driver will only check this on query execution, not when preparing statements…) See also https://github.com/quarkusio/quarkus/issues/32539 ( https://hibernate.atlassian.net/browse/HHH-16458#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16458#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#100221- sha1:c4871f2 )

3 years

1
0
0 / 0

[JIRA] (HHH-16457) Values returned in ValueAccess.getValues() and getValue(…) not alphabetical for Java records

by Oliver Drotbohm (JIRA)

Oliver Drotbohm ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=62861a8... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiYWI3N2NkMjg2... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16457?atlOrigin=eyJpIjoiYWI3N2... ) HHH-16457 ( https://hibernate.atlassian.net/browse/HHH-16457?atlOrigin=eyJpIjoiYWI3N2... ) Values returned in ValueAccess.getValues() and getValue(…) not alphabetical for Java records ( https://hibernate.atlassian.net/browse/HHH-16457?atlOrigin=eyJpIjoiYWI3N2... ) Change By: Oliver Drotbohm ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=62861a8... ) The Javadoc of {{ValueAccess.getValues()}} states: {code:java}/** * Access to an individual value. * * @apiNote It is important to remember that attributes are * sorted alphabetically. So the values here will be in alphabetically * order according to the names of the corresponding attribute */{code} For a Java record declaration like this: {code:java}record MyRecord(int c, String b, LocalDate a) {}{code} on Hibernate 6.1.7, {{ValueAccess.getValues()}} returns the {{LocalDate}} first, the {{String}} second, the integer last, i.e. alphabetically as defined in the Javadoc. On Hibernate 6.2, the same method invocation returns the integer first, the {{String}} second and the {{LocalDate}} last, i.e. as declared in the constructor but _not_ as specified in the Javadoc. This change of behavior is also evident when trying to access values by index , i. e. {{ValueAccess.getValue(…)}}. h2. Steps to reproduce {noformat}$ git clone https://github.com/odrotbohm/hibernate-bugs $ cd hibernate-bugs/embeddable-instantiator $ mvn clean test // Success - Hibernate 6.1.7 // Change hibernate.version property in pom.xml to 6.2.0.Final $ mvn clean test // See test fail with java.lang.ClassCastException: Cannot cast java.time.LocalDate to java.lang.Integer at java.base/java.lang.Class.cast(Class.java:3889) at org.hibernate.metamodel.spi.ValueAccess.getValue(ValueAccess.java:33) at example.MyRecord$MyRecordInstantiator.instantiate(MyRecord.java:56){noformat} ( https://hibernate.atlassian.net/browse/HHH-16457#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16457#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#100221- sha1:c4871f2 )

3 years

1
0
0 / 0

[JIRA] (HHH-16448) After upgrading to Hibernate 6.2.0.Final, the unique attribute of `@JoinColumn` always behaves as true.

by Andrea Boriero (JIRA)

3 years

1
0
0 / 0

[JIRA] (HHH-16448) After upgrading to Hibernate 6.2.0.Final, the unique attribute of `@JoinColumn` always behaves as true.

by Andrea Boriero (JIRA)

Andrea Boriero ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16448 ( https://hibernate.atlassian.net/browse/HHH-16448?atlOrigin=eyJpIjoiZTY2YT... ) Re: After upgrading to Hibernate 6.2.0.Final, the unique attribute of `@JoinColumn` always behaves as true. ( https://hibernate.atlassian.net/browse/HHH-16448?atlOrigin=eyJpIjoiZTY2YT... ) Hi mklinkj ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) , I’m going to close the Jira. ( https://hibernate.atlassian.net/browse/HHH-16448#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16448#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#100221- sha1:c4871f2 )

3 years

1
0
0 / 0

[JIRA] (HHH-16448) After upgrading to Hibernate 6.2.0.Final, the unique attribute of `@JoinColumn` always behaves as true.

by mklinkj (JIRA)

3 years

1
0
0 / 0

[JIRA] (HV-1945) @LuhnCheck with endIndex and checkDigitIndex equals seems wrong

by Claudio Nave (JIRA)

Claudio Nave ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=70121%3... ) *created* an issue Hibernate Validator ( https://hibernate.atlassian.net/browse/HV?atlOrigin=eyJpIjoiNGQ0ZjRhNGJlY... ) / Bug ( https://hibernate.atlassian.net/browse/HV-1945?atlOrigin=eyJpIjoiNGQ0ZjRh... ) HV-1945 ( https://hibernate.atlassian.net/browse/HV-1945?atlOrigin=eyJpIjoiNGQ0ZjRh... ) @LuhnCheck with endIndex and checkDigitIndex equals seems wrong ( https://hibernate.atlassian.net/browse/HV-1945?atlOrigin=eyJpIjoiNGQ0ZjRh... ) Issue Type: Bug Affects Versions: 8.0.0.Final Assignee: Unassigned Components: documentation, validators Created: 11/Apr/2023 14:06 PM Priority: Major Reporter: Claudio Nave ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=70121%3... ) Hi, I’m working on a project that needs to generate random data that passes the Hibernate validation. The documentation for the checkDigitIndex field of the @LuhnCheck annotation states that > > > > The index of the check digit in the input. Per default it is assumed that > the check digit is the last digit of the specified range. If set, the > digit at the specified index is used. If set the following must hold true: > checkDigitIndex > 0 && (checkDigitIndex < startIndex || checkDigitIndex >= > endIndex. > > So it’s possible that checkDigitIndex == endIndex, but I don’t think to understand the logic of the current implementation of this case. For me the checkDigitIndex being equal to the endIndex should mean that the digit at endIndex position is considered the check digit, but not part of the number that is being checked. To clarifiy a bit if I have a string “12345” with endIndex = 4 and checkDigitIndex = 4 the logical approach for me is to do luhnCheckDigit(1234) == 5. But the current implementation is much more literal and uses the checkDigitIndex as both the check digit and part of the number being validated luhnCheckDigit(12345) = 5. This is technically correct but it doesn’t seem quite right. Considering that if checkDigitIndex is not manually set the check digit is assumed to be the last digit of the sequence, but in that case the last digit of the sequence is excluded from the luhnCheckDigit computation. So for example the same string “12345” with only endIndex = 4 behaves like it should with luhnCheckDigit(1234) = 5. It seems to me that something is off with all of this. The case of checkDigitIndex == endIndex should be handled in a similar way to when checkDigitIndex isn’t specified and it’s assumed to be the last digit. I can help providing a PR for this if you want. Bye! ( https://hibernate.atlassian.net/browse/HV-1945#add-comment?atlOrigin=eyJp... ) Add Comment ( https://hibernate.atlassian.net/browse/HV-1945#add-comment?atlOrigin=eyJp... ) 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#100221- sha1:9ff53d8 )

3 years

1
0
0 / 0

[JIRA] (HHH-16457) Values returned in ValueAccess.getValues() and getValue(…) not alphabetical for Java records

by Oliver Drotbohm (JIRA)

Oliver Drotbohm ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=62861a8... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiNmRlMzAzNmNk... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16457?atlOrigin=eyJpIjoiNmRlMz... ) HHH-16457 ( https://hibernate.atlassian.net/browse/HHH-16457?atlOrigin=eyJpIjoiNmRlMz... ) Values returned in ValueAccess.getValues() and getValue(…) not alphabetical for Java records ( https://hibernate.atlassian.net/browse/HHH-16457?atlOrigin=eyJpIjoiNmRlMz... ) Issue Type: Bug Affects Versions: 6.2.0 Assignee: Unassigned Created: 11/Apr/2023 12:56 PM Priority: Major Reporter: Oliver Drotbohm ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=62861a8... ) The Javadoc of ValueAccess.getValues() states: /** * Access to an individual value. * * @apiNote It is important to remember that attributes are * sorted alphabetically. So the values here will be in alphabetically * order according to the names of the corresponding attribute */ For a Java record declaration like this: record MyRecord( int c, String b, LocalDate a) {} on Hibernate 6.1.7, ValueAccess.getValues() returns the LocalDate first, the String second, the integer last, i.e. alphabetically as defined in the Javadoc. On Hibernate 6.2, the same method returns the integer first, the String second and the LocalDate last, i.e. as declared in the constructor but not as specified in the Javadoc. This change of behavior is also evident when trying to access values by index. ------------------ Steps to reproduce ------------------ $ git clone https://github.com/odrotbohm/hibernate-bugs $ cd hibernate-bugs/embeddable-instantiator $ mvn clean test // Success - Hibernate 6.1.7 // Change hibernate.version property in pom.xml to 6.2.0.Final $ mvn clean test // See test fail with java.lang.ClassCastException: Cannot cast java.time.LocalDate to java.lang.Integer at java.base/java.lang.Class.cast(Class.java:3889) at org.hibernate.metamodel.spi.ValueAccess.getValue(ValueAccess.java:33) at example.MyRecord$MyRecordInstantiator.instantiate(MyRecord.java:56) ( https://hibernate.atlassian.net/browse/HHH-16457#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16457#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#100221- sha1:9ff53d8 )

3 years

1
0
0 / 0

[JIRA] (HHH-16448) After upgrading to Hibernate 6.2.0.Final, the unique attribute of `@JoinColumn` always behaves as true.

by mklinkj (JIRA)

mklinkj ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16448 ( https://hibernate.atlassian.net/browse/HHH-16448?atlOrigin=eyJpIjoiOTQ0OT... ) Re: After upgrading to Hibernate 6.2.0.Final, the unique attribute of `@JoinColumn` always behaves as true. ( https://hibernate.atlassian.net/browse/HHH-16448?atlOrigin=eyJpIjoiOTQ0OT... ) Thank you for answer. I made a mistake. Despite using @OneToOne , the initial data was incorrectly entered as data in which Strudent has multiple MembershipCards. The table auto-creation statement created by 6.2.0 is correct. Next time I report, I'll check more and post it. 😅 thank you. ( https://hibernate.atlassian.net/browse/HHH-16448#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16448#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#100221- sha1:9ff53d8 )

3 years

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 April 2023