[JIRA] (HHH-16013) Lazy loading fails with "Generation of HibernateProxy instances at runtime is not allowed" when run as native
by Sanne Grinovero (JIRA)
Sanne Grinovero ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16013 ( https://hibernate.atlassian.net/browse/HHH-16013?atlOrigin=eyJpIjoiZjA2Mj... )
Re: Lazy loading fails with "Generation of HibernateProxy instances at runtime is not allowed" when run as native ( https://hibernate.atlassian.net/browse/HHH-16013?atlOrigin=eyJpIjoiZjA2Mj... )
Hi cstrobl ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=630ccdd... ) I agree with your suggestion at high level, but I won’t have the bandwith to implement such changes. Contributions are very welcome. Frankly I don’t think it’s viable for us to make Hibernate ORM work out of the box in any custom framework within GraalVM native images - each runtime will need to plug or drive some customization, especially if one wants an optimised output; I’d dare say that if people don’t care about an optimised output, then there’s no point to look into native images at all so the optimal output is an hard requirement.
So I’ll welcome PRs that improve and allow any framework to have more control on such details, but I don’t think it’s a viable plan to make any use of Hibernate ORM simply compile to native out of the box. Also because of diminishing returns, there’s very few non-advanced users who will not be using a runtime framework to bootstrap Hibernate, so such a limitation is acceptable.
Regarding to the codepaths leading to the inclusion of ByteBuddy - I think I’ve improved that in https://hibernate.atlassian.net/browse/HHH-16058 ( https://hibernate.atlassian.net/browse/HHH-16058 ). A further improvement, could be to move the actual ByteBuddy integration code into a different jar, so to make it easier to exclude from the classpath when compiling a native image. I think the current code will already lead into a full exclusion of such code when creating a binary, but clearly that’s easier to verify and maintain if we make this code fully optional.
Again I don’t think I’ll have bandwith to extract that code into a separate module myself soon, but I’d welcome pull requests and would be happy to review them.
( https://hibernate.atlassian.net/browse/HHH-16013#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16013#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#100214- sha1:fcee39f )
1 year, 3 months
[JIRA] (HHH-16128) Parameters out of order on inner join with entities with @Inheritance(strategy = InheritanceType.JOINED)
by Jose Freire (JIRA)
Jose Freire ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiNWE3MDgxNzc4... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-16128?atlOrigin=eyJpIjoiNWE3MD... ) HHH-16128 ( https://hibernate.atlassian.net/browse/HHH-16128?atlOrigin=eyJpIjoiNWE3MD... ) Parameters out of order on inner join with entities with @Inheritance(strategy = InheritanceType.JOINED) ( https://hibernate.atlassian.net/browse/HHH-16128?atlOrigin=eyJpIjoiNWE3MD... )
Change By: Jose Freire ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... )
Having the following entities:
{code:java}@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public class TestClassSuper implements Serializable {
private static final long serialVersionUID = 1L;
private Long id;
private String text;
private Date date;
private BigDecimal number;
....
}
@Entity
public class TestClassA extends TestClassSuper {
private static final long serialVersionUID = 1L;
private Long id;
....
}
@Entity
public class TestClassB extends TestClassSuper {
private static final long serialVersionUID = 1L;
private Long id;
....
}{code}
The following HQL:
{code:sql}SELECT a.id
FROM org.hibernate.bugs.testclassa a
LEFT JOIN org.hibernate.bugs.testclassa c
ON a.id = c.id AND c.date = :date
LEFT JOIN org.hibernate.bugs.testclassb b
ON a.id = b.id AND a.text = :text{code}
Produces the SQL:
{code:sql}SELECT testclassa0_.id AS col_0_0_
FROM testclassa testclassa0_
INNER JOIN testclasssuper testclassa0_1_
ON testclassa0_.id = testclassa0_1_.id
LEFT OUTER JOIN ( testclassa testclassa1_
INNER JOIN testclasssuper testclassa1_1_
ON testclassa1_.id = testclassa1_1_.id )
ON ( testclassa0_.id = testclassa1_.id
AND testclassa1_1_.date = ? )
LEFT OUTER JOIN ( testclassb testclassb2_
INNER JOIN testclasssuper testclassb2_1_
ON testclassb2_.id = testclassb2_1_.id )
ON ( testclassa0_.id = testclassb2_.id
AND testclassa0_1_.text = ? ){code}
However, by changing the first LEFT JOIN to INNER JOIN in the HQL:
{code:sql}SELECT a.id
FROM org.hibernate.bugs.testclassa a
INNER JOIN org.hibernate.bugs.testclassa c
ON a.id = c.id AND c.date = :date
LEFT JOIN org.hibernate.bugs.testclassb b
ON a.id = b.id AND a.text = :text{code}
Produces the SQL:
{code:sql}SELECT testclassa0_.id AS col_0_0_
FROM testclassa testclassa0_
INNER JOIN testclasssuper testclassa0_1_
ON testclassa0_.id = testclassa0_1_.id
INNER JOIN testclassa testclassa1_
ON 1 = 1
INNER JOIN testclasssuper testclassa1_1_
ON testclassa1_.id = testclassa1_1_.id
LEFT OUTER JOIN ( testclassb testclassb2_
INNER JOIN testclasssuper testclassb2_1_
ON testclassb2_.id = testclassb2_1_.id )
ON ( testclassa0_.id = testclassb2_.id
AND testclassa0_1_.text = ? )
WHERE ( testclassa0_.id = testclassa1_.id
AND testclassa1_1_.date = ? ){code}
The parameter sequence has changed!
In the first query the parameter sequence in the query is: date, text.
In the second query the parameter sequence in the query is: text, date.
But the binding order for the second query is the same as the first query, thus the cast exception on SQL Server:
{code:java}Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Conversion failed when converting date and/or time from character string.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:265)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet$FetchBuffer.nextRow(SQLServerResultSet.java:5479)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet.fetchBufferNext(SQLServerResultSet.java:1798)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet.next(SQLServerResultSet.java:1056)
at org.hibernate.loader.Loader.getRowsFromResultSet(Loader.java:1043)
at org.hibernate.loader.Loader.processResultSet(Loader.java:998)
at org.hibernate.loader.Loader.doQuery(Loader.java:967)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:357)
at org.hibernate.loader.Loader.doList(Loader.java:2868){code}
Hibernate is binding the parameter of type ‘date’ into the binding position ‘0', but the ‘date’ parameter position has changed to the binding position '1’.
-Attached is a test case, however I couldn’t reproduce with H2 database. My guess is that H2 doesn’t care, because the generated SQL is identical-.
Attached a new test case (TestCase-ParametersOutOfOrder-2.tar.gz), much simpler and works with H2 database.
This new test case may increase the severity of the bug, because it can silently return the wrong results in query.
( https://hibernate.atlassian.net/browse/HHH-16128#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16128#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#100214- sha1:fcee39f )
1 year, 3 months