November 2022 - hibernate-issues - Jboss List Archives

[JIRA] (HHH-15737) Support for Inheritance and Bytecode Enchanced Lazy Loading

by Alessandro Moscatelli (JIRA)

Alessandro Moscatelli ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ad61be... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMGJiMmFhMGZl... ) / New Feature ( https://hibernate.atlassian.net/browse/HHH-15737?atlOrigin=eyJpIjoiMGJiMm... ) HHH-15737 ( https://hibernate.atlassian.net/browse/HHH-15737?atlOrigin=eyJpIjoiMGJiMm... ) Support for Inheritance and Bytecode Enchanced Lazy Loading ( https://hibernate.atlassian.net/browse/HHH-15737?atlOrigin=eyJpIjoiMGJiMm... ) Issue Type: New Feature Assignee: Unassigned Components: bytecode-enhancement Created: 21/Nov/2022 03:23 AM Priority: Major Reporter: Alessandro Moscatelli ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ad61be... ) Hi everybody ! I understand that at the moment you decided to resort to HibernateProxy when lazy loading and Entity that may be instance of a superclass or of a subtype. This is to completely avoid hitting the database (and to be completely lazy). Well, I believe this behaviour should be configurable, especially when we enable bytecode enhancement, since this breaks code based on “instanceof” predicates, getClass(), or APIs that use unproxofied classes like jakarta.persistence.metamodel.MetaModel.entity and many other. I am suggesting introducing a configuration to be lazy on everything with the exception of the type information. Example of what I am proposing : I am using bytecode enhancement, when Hibernate retrieves a Person, that may also be a NaturalPerson or a LegalPerson, it should make a 'minimal' hit on the database to retrieve the type information (according to the inheritance strategy, all of them should be supported) and return the instance accordingly instead of a proxy. Then any other lazy behaviour on Person type or subtype on any property can occur as before. The same happens for entities having a polymorphic ToOne relation. Credential is bytecode enhanced and has a ToOne relation with Person. When Hibernate retrieves a Credential, the Person property is set to null. When I call the getPerson() getter method, Hibernate makes the minimal query to determine the type information (according to the inheritance strategy, all of them should be supported), and return an instance accordingly. I think the same could be applied to the ToMany relations, but I am not an expert here since I usually avoid to use/navigate using this kind of relations. This behaviour can be summarized with “Lazy Loading with Eager Type Information”. Of course this makes more hits than actual behaviour, this is why I believe this could be activated with a custom hibernate property, to determine what the user really wants. Of course, queries to determine the type information should really be minimal, they should involve only the necessary columns and external ids in case of JOINED strategy. The rationale of this feature request is that on old versions of Hibernate, 5.3 for sure, when using bytecode enhacement and lazy loaded polymorphic relations they defaulted to EAGER instead of using proxies. But the new behaviour can break projects, like mine, preventing the upgrade. What do you think ? I hope I explained myself. ( https://hibernate.atlassian.net/browse/HHH-15737#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-15737#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#100210- sha1:9b34d7c )

3 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-3513) Entity change event sourcing through Debezium

by Yoann Rodière (JIRA)

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiMjljOTVh... ) / Epic ( https://hibernate.atlassian.net/browse/HSEARCH-3513?atlOrigin=eyJpIjoiMjl... ) HSEARCH-3513 ( https://hibernate.atlassian.net/browse/HSEARCH-3513?atlOrigin=eyJpIjoiMjl... ) Entity change event sourcing through Debezium ( https://hibernate.atlassian.net/browse/HSEARCH-3513?atlOrigin=eyJpIjoiMjl... ) Change By: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) The main advantage compared to client-side event sourcing would be the ability to detect "batch" changes caused by update/delete queries, which currently are not detected. For example if the user updates the property {{name}} in a thousand {{Person}} entities using {{UPDATE Person p SET p.name = CONCAT(p.name, 'foo')}}, this change currently is never detected by Hibernate Search. The user has to take care to reindex affected entities manually. Once [https://hibernate.atlassian.net/browse/HSEARCH-3280|https://hibernate.atl... addressed, we will have most of the infrastructure ready to support Debezium in Hibernate Search. The main problem will be to create a Debezium plugin that allows to: * Define the events we're interested in at the Hibernate ORM entity level, instead of the table level (i.e. translate"I'm interested in property {{myEmbeddable.property1}} of entity {{MyEntity}}" into "I'm interested in column {{myEmbeddable_property1}} of table {{myentity}}". * Ideally, send entity-scoped events instead of table-scoped event, with the same format as what we envision for entity change events in [https://hibernate.atlassian.net/browse/HSEARCH- 3281 3280 |https://hibernate.atlassian.net/browse/HSEARCH- 3281 3280 |smart-link] Optimistically planning this for 6.1, but we will need to work very hard with the Debezium team to address the two points above. Interesting, related documentation: [https://docs.confluent.io/platform/current/streams/architecture.html#stre...] ( https://hibernate.atlassian.net/browse/HSEARCH-3513#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-3513#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#100210- sha1:9b34d7c )

3 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-3513) Entity change event sourcing through Debezium

by Yoann Rodière (JIRA)

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiNTcxMDYz... ) / Epic ( https://hibernate.atlassian.net/browse/HSEARCH-3513?atlOrigin=eyJpIjoiNTc... ) HSEARCH-3513 ( https://hibernate.atlassian.net/browse/HSEARCH-3513?atlOrigin=eyJpIjoiNTc... ) Entity change event sourcing through Debezium ( https://hibernate.atlassian.net/browse/HSEARCH-3513?atlOrigin=eyJpIjoiNTc... ) Change By: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) The main advantage compared to client-side event sourcing would be the ability to detect "batch" changes caused by update/delete queries, which currently are not detected. For example if the user updates the property {{name}} in a thousand {{Person}} entities using {{UPDATE Person p SET p.name = CONCAT(p.name, 'foo')}}, this change currently is never detected by Hibernate Search. The user has to take care to reindex affected entities manually. Once [https://hibernate.atlassian.net/browse/HSEARCH-3280|https://hibernate.atl... addressed, we will have most of the infrastructure ready to support Debezium in Hibernate Search. The main problem will be to create a Debezium plugin that allows to: * Define the events we're interested in at the Hibernate ORM entity level, instead of the table level (i.e. translate"I'm interested in property {{myEmbeddable.property1}} of entity {{MyEntity}}" into "I'm interested in column {{myEmbeddable_property1}} of table {{myentity}}". * Ideally, send entity-scoped events instead of table-scoped event, with the same format as what we envision for entity change events in [https://hibernate.atlassian.net/browse/ HSEARCH-3281 |https://hibernate.atlassian.net/browse/HSEARCH-3281|smart-link] Optimistically planning this for 6.1, but we will need to work very hard with the Debezium team to address the two points above. Interesting, related documentation: [https://docs.confluent.io/platform/current/streams/architecture.html#stre...] ( https://hibernate.atlassian.net/browse/HSEARCH-3513#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-3513#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#100210- sha1:9b34d7c )

3 years, 4 months

1
0
0 / 0

[JIRA] (HBX-2432) Implement and use the generic adapter for IConfiguration in the experimental Hibernate runtime

by Koen Aers (JIRA)

3 years, 4 months

1
0
0 / 0

[JIRA] (HBX-2433) Create an experimental Hibernate runtime that will use the new Hibernate Tools ORM to JBoss Tools adapter layer

by Koen Aers (JIRA)

3 years, 4 months

1
0
0 / 0

[JIRA] (HBX-2390) Create a JBoss Tools adaptation layer

by Koen Aers (JIRA)

3 years, 4 months

1
0
0 / 0

[JIRA] (HBX-2432) Implement and use the generic adapter for IConfiguration in the experimental Hibernate runtime

by Koen Aers (JIRA)

3 years, 4 months

1
0
0 / 0

[JIRA] (HBX-2431) Update version identifier to 5.6.15.Final

by Koen Aers (JIRA)

3 years, 4 months

1
0
0 / 0

[JIRA] (HBX-2430) Update Hibernate ORM Dependency to Version 5.6.15.Final

by Koen Aers (JIRA)

3 years, 4 months

1
0
0 / 0

[JIRA] (HBX-2424) Update version identifier to 5.6.14.Final

by Koen Aers (JIRA)

3 years, 4 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 November 2022