June 2023 - hibernate-issues - Jboss List Archives

[JIRA] (HHH-16697) CALCULATED FIELDS in createNativeQuery doExtract integer insted of BigDecimals.

by Isaac Vásquez (JIRA)

Isaac Vásquez ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=627d288... ) *commented* on HHH-16697 ( https://hibernate.atlassian.net/browse/HHH-16697?atlOrigin=eyJpIjoiNzVmM2... ) Re: CALCULATED FIELDS in createNativeQuery doExtract integer insted of BigDecimals. ( https://hibernate.atlassian.net/browse/HHH-16697?atlOrigin=eyJpIjoiNzVmM2... ) @Sanne Grinovero, Hi, thanks you, the apologies of the case ( https://hibernate.atlassian.net/browse/HHH-16697#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16697#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#100225- sha1:40c4da4 )

2 years, 10 months

1
0
0 / 0

[JIRA] (HSEARCH-4862) Upgrade to Hibernate ORM 5.3.30.Final

by Automation for Jira (JIRA)

2 years, 10 months

1
0
0 / 0

[JIRA] (HSEARCH-4862) Upgrade to Hibernate ORM 5.3.30.Final

by Yoann Rodière (JIRA)

2 years, 10 months

1
0
0 / 0

[JIRA] (HSEARCH-4862) Upgrade to Hibernate ORM 5.3.30.Final

by Yoann Rodière (JIRA)

2 years, 10 months

1
0
0 / 0

[JIRA] (HHH-16737) Interpretation of numeric literals without explicit type suffix

by Marcus Klimstra (JIRA)

Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMDVmZGVlNmVl... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiMDVmZG... ) HHH-16737 ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiMDVmZG... ) Interpretation of numeric literals without explicit type suffix ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiMDVmZG... ) Change By: Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) This could be either a documentation or implementation issue. Section “16.3.3. Numeric literals” of the documentation shows some examples of numeric literals, with and without explicit type suffixes: * “1” is indicated as a “simple integer literal”; * “1L” is a “simple integer literal, typed as a long”; * “100.5” is “decimal notation”; * “100.5F” is “decimal notation, typed as a float”; * “1e+2” is “scientific notation”; * “1e+2F” is “scientific notation, typed as a float”. It also states that “It’s not usually necessary to specify the precision explicitly.” The problem I have with this is that it does not state how literals are interpreted when the type suffix is not specified. My initial reading was that “100.5” would be interpreted as a BigDecimal. This is because the term “decimal” itself is a bit ambiguous, and the example is distinguished from the next one, which is indicated as “typed as float”. However, it seems that it is in fact interpreted as float. I ran into this with a value that cannot be exactly represented as a float: {{SELECT b.isbn, b.title, b.score FROM Book b WHERE b.score = 199999.99}} Is translated to: {{select b1_0.ISBN_,b1_0.TITLE_,b1_0.SCORE_ from BOOK b1_0 where b1_0.SCORE_=199999.98}} (Note that Book.score is a BigDecimal in the Java model class) So IMO it would help if the documentation would explicitly state how such literals are interpreted. One might also wonder if float (rather than say, double) is a good default representation. In Java, according to the JLS Section 3.10.2, "Floating-Point Literals," a floating-point literal without a suffix is of type {{double}} by default. The JPA 3.1 spec states that “Approximate literals support the use Java floating point literal syntax as well as SQL approximate numeric literal syntax.” This would suggest to me that {{double}} should be the default for JPQL as well. ( https://hibernate.atlassian.net/browse/HHH-16737#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16737#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#100225- sha1:40c4da4 )

2 years, 10 months

1
0
0 / 0

[JIRA] (HHH-16737) Interpretation of numeric literals without explicit type suffix

by Marcus Klimstra (JIRA)

Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMGE3ZmM1N2Vk... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiMGE3Zm... ) HHH-16737 ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiMGE3Zm... ) Interpretation of numeric literals without explicit type suffix ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiMGE3Zm... ) Change By: Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) This could be either a documentation or implementation issue. Section “16.3.3. Numeric literals” of the documentation shows some examples of numeric literals, with and without explicit type suffixes: * “1” is indicated as a “simple integer literal”; * “1L” is a “simple integer literal, typed as a long”; * “100.5” is “decimal notation”; * “100.5F” is “decimal notation, typed as a float”; * “1e+2” is “scientific notation”; * “1e+2F” is “scientific notation, typed as a float”. It also states that “It’s not usually necessary to specify the precision explicitly.” The problem I have with this is that it does not state how literals are interpreted when the type suffix is not specified. My initial reading was that “100.5” would be interpreted as a BigDecimal. This is because the term “decimal” itself is a bit ambiguous, and the example is distinguished from the next one, which is indicated as “typed as float”. However, it seems that it is in fact interpreted as float. I ran into this with a value that cannot be exactly represented as a float: {{SELECT b.isbn, b.title, b.score FROM Book b WHERE b.score = 199999.99}} Is translated to: {{select b1_0.ISBN_,b1_0.TITLE_,b1_0.SCORE_ from BOOK b1_0 where b1_0.SCORE_=199999.98}} (Note that Book.score is a BigDecimal in the Java model class) So IMO it would help if the documentation would explicitly state how such literals are interpreted. One might also wonder if float (rather than say, double) is a good default representation. In Java, according to the JLS Section 3.10.2, "Floating-Point Literals," a floating-point literal without a suffix is of type {{double}} by default. The JPA 3.1 spec states that “Approximate literals support the use Java floating point literal syntax as well as SQL approximate numeric literal syntax.” ( https://hibernate.atlassian.net/browse/HHH-16737#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16737#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#100225- sha1:40c4da4 )

2 years, 10 months

1
0
0 / 0

[JIRA] (HHH-16729) Instantiate a proxy of the correct class for ManyToOne associated to an inheritance hierarchy

by Guillaume Toison (JIRA)

Guillaume Toison ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=70121%3... ) *commented* on HHH-16729 ( https://hibernate.atlassian.net/browse/HHH-16729?atlOrigin=eyJpIjoiNGU3OD... ) Re: Instantiate a proxy of the correct class for ManyToOne associated to an inheritance hierarchy ( https://hibernate.atlassian.net/browse/HHH-16729?atlOrigin=eyJpIjoiNGU3OD... ) I don’t want a pony, I want to keep using the donkey I already have 🙂 Basically I’m using @Proxy(lazy = false) to ensure that objects in an inheritance hierarchy have the right class, at the expense of relaxing the performance requirement (this breaks lazy loading). In Hibernate 6.2 proxy loading seem to have changed because I get new errors, and these errors go away when I remove @Proxy(lazy = false) , I’m trying to pinpoint the problem but was not successful so far, for instance https://hibernate.atlassian.net/browse/HHH-16553 or https://discourse.hibernate.org/t/objectnotfoundexception-in-6-2-when-reu... So I’ll keep trying to debug these errors, most probably the problem is in my code. Thanks a lot for the answers; I’ll close this unless you tell me otherwise ( https://hibernate.atlassian.net/browse/HHH-16729#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16729#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#100225- sha1:40c4da4 )

2 years, 10 months

1
0
0 / 0

[JIRA] (HHH-16737) Interpretation of numeric literals without explicit type suffix

by Marcus Klimstra (JIRA)

Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiOWZiMjhmZmEz... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiOWZiMj... ) HHH-16737 ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiOWZiMj... ) Interpretation of numeric literals without explicit type suffix ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiOWZiMj... ) Change By: Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) This could be either a documentation or implementation issue. Section “16.3.3. Numeric literals” of the documentation shows some examples of numeric literals, with and without explicit type suffixes: * “1” is indicated as a “simple integer literal”; * “1L” is a “simple integer literal, typed as a long”; * “100.5” is “decimal notation”; * “100.5F” is “decimal notation, typed as a float”; * “1e+2” is “scientific notation”; * “1e+2F” is “scientific notation, typed as a float”. It also states that “It’s not usually necessary to specify the precision explicitly.” The problem I have with this is that it does not state how literals are interpreted when the type suffix is not specified. My initial reading was that “100.5” would be interpreted as a BigDecimal. This is because the term “decimal” itself is a bit ambiguous, and the example is distinguished from the next one, which is indicated as “typed as float”. However, it seems that it is in fact interpreted as float. I ran into this with a value that cannot be exactly represented as a float: {{SELECT b.isbn, b.title, b.score FROM Book b WHERE b.score = 199999.99}} Is translated to: {{select b1_0.ISBN_,b1_0.TITLE_,b1_0.SCORE_ from BOOK b1_0 where b1_0.SCORE_=199999.98}} (Note that Book.score is a BigDecimal in the Java model class) So IMO it would help if the documentation would explicitly state how such literals are interpreted. One might also wonder if float (rather than say, double) is a good default representation. In Java, according to the JLS Section 3.10.2, "Floating-Point Literals," a floating-point literal without a suffix is of type {{double}} by default. ( https://hibernate.atlassian.net/browse/HHH-16737#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16737#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#100225- sha1:40c4da4 )

2 years, 10 months

1
0
0 / 0

[JIRA] (HHH-16737) Interpretation of numeric literals without explicit type suffix

by Marcus Klimstra (JIRA)

Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiYWNmMTU0OTNm... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiYWNmMT... ) HHH-16737 ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiYWNmMT... ) Interpretation of numeric literals without explicit type suffix ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiYWNmMT... ) Change By: Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) This could be either a documentation or implementation issue. Section “16.3.3. Numeric literals” of the documentation shows some examples of numeric literals, with and without explicit type suffixes: * “1” is indicated as a “simple integer literal”; * “1L” is a “simple integer literal, typed as a long”; * “100.5” is “decimal notation”; * “100.5F” is “decimal notation, typed as a float”; * “1e+2” is “scientific notation”; * “1e+2F” is “scientific notation, typed as a float”. It also states that “It’s not usually necessary to specify the precision explicitly.” The problem I have with this is that it does not state how literals are interpreted when the type suffix is not specified. My initial reading was that “100.5” would be interpreted as a BigDecimal. This is because the term “decimal” itself is a bit ambiguous, and the example is distinguished from the next one, which is indicated as “typed as float”. However, it seems that it is in fact interpreted as float. I ran into this with a value that cannot be exactly represented as a float: {{SELECT b.isbn, b.title, b.score , b.author.firstName FROM Book b WHERE b.score = 199999.99}} Is translated to: {{select b1_0.ISBN_,b1_0.TITLE_,b1_0.SCORE_ ,a1_0.FIRST_NAME_ from BOOK b1_0 join AUTHOR a1_0 on a1_0.id=b1_0.author_id where b1_0.SCORE_=199999.98}} (Note that Book.score is a BigDecimal in the Java model class) So IMO it would help if the documentation would explicitly state how such literals are interpreted. One might also wonder if float (rather than say, double) is a good default representation. ( https://hibernate.atlassian.net/browse/HHH-16737#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16737#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#100225- sha1:40c4da4 )

2 years, 10 months

1
0
0 / 0

[JIRA] (HHH-16737) Interpretation of numeric literals without explicit type suffix

by Marcus Klimstra (JIRA)

Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiOWIzYmMzOGUx... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiOWIzYm... ) HHH-16737 ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiOWIzYm... ) Interpretation of numeric literals without explicit type suffix ( https://hibernate.atlassian.net/browse/HHH-16737?atlOrigin=eyJpIjoiOWIzYm... ) Issue Type: Bug Affects Versions: 6.2.4 Assignee: Unassigned Components: documentation Created: 01/Jun/2023 05:38 AM Priority: Major Reporter: Marcus Klimstra ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) This could be either a documentation or implementation issue. Section “16.3.3. Numeric literals” of the documentation shows some examples of numeric literals, with and without explicit type suffixes: * “1” is indicated as a “simple integer literal”; * “1L” is a “simple integer literal, typed as a long”; * “100.5” is “decimal notation”; * “100.5F” is “decimal notation, typed as a float”; * “1e+2” is “scientific notation”; * “1e+2F” is “scientific notation, typed as a float”. It also states that “It’s not usually necessary to specify the precision explicitly.” The problem I have with this is that it does not state how literals are interpreted when the type suffix is not specified. My initial reading was that “100.5” would be interpreted as a BigDecimal. This is because the term “decimal” itself is a bit ambiguous, and the example is distinguished from the next one, which is indicated as “typed as float”. However, it seems that it is in fact interpreted as float. I ran into this with a value that cannot be exactly represented as a float: SELECT b.isbn, b.title, b.score, b.author.firstName FROM Book b WHERE b.score = 199999.99 Is translated to: select b1_0.ISBN_,b1_0.TITLE_,b1_0.SCORE_,a1_0.FIRST_NAME_ from BOOK b1_0 join AUTHOR a1_0 on a1_0.id=b1_0.author_id where b1_0.SCORE_=199999.98 (Note that Book.score is a BigDecimal in the Java model class) So IMO it would help if the documentation would explicitly state how such literals are interpreted. One might also wonder if float (rather than say, double) is a good default representation. ( https://hibernate.atlassian.net/browse/HHH-16737#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16737#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#100225- sha1:40c4da4 )

2 years, 10 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 June 2023