Composite User Types work like regular Composite Types (like Embeddable) in HQL. However, because they cannot be represented in the JPA metamodel, libraries like [GraphQL for JPA](https://github.com/jcrygier/graphql-jpa) or [Blaze-Persistence](https://persistence.blazebit.com/) cannot fully utilize them. In order to make the composite property names available to these libraries, it would be nice to optionally expose these attributes as embedded attributes. This pull request aims to make that change and makes it configurable through a custom setting.
Composite User Types are a common solution for mapping composite interfaces. A common example is for example `Money` from the Java Money API (JSR-354), for which composite user types are implemented in [Jadira](http://jadira.sourceforge.net/usertype-userguide.html).
I know Composite User Types are currently not consiered in Hibernate 6.x. See also [this](https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/CompositeUserType) Zulip thread. I am not sure if Hibernate 6.x will even have multi column types, which I presume would be a requirement to even introduce Composite User types back at some point. Usually Embeddables are a much easier, suitable mechanism for composite user types. But Embeddables are not always a viable alternative, because Embeddables require the type to be subclassed (as an interface cannot be mapped, and the type may not solely comprise fields that can be mapped to a simple basic type). To deal with this exact problem, `MonetaryAmounts` are still mapped as composite user type. There also have been suggestions to the JPA Spec to consider `AttributeConverters` for Embeddables for pracitcally the same purpose (which I think is going to be a mess of an implementation). See: https://github.com/eclipse-ee4j/jpa-api/issues/105
Anyways, regardless of whether this gets integrated in 5.x, I don't expect it to be integrated in 6.x unless we also reintroduce Composite User Types. I am willing to contribute Composite User Types for 6.x if people see benefit in it and think it can be done in the first place.
- avoid use package-scoped instance felds
- remove copy/pasted code
Note: I don't hate package-scoped final fields, but I
know other folks tend to. So let's go with template
methods instead.
This extends the optimization for single-table HQL bulk
updates to the case where the where clause touches multiple
tables and we can use a subselect to collect the ids that
we need to update.
introduces InsertExecutor and UpdateExecutor since we're
going to be introducing specific optimizations relating
to single-table updates
relates to HHH-14153
When a HQL bulk update query only touches a single table,
use BasicExecutor instead of MultiTableUpdateExecutor.
This is an alternate implementation to the one proposed by
@NathanQingyangXu in #3508 and loosely based on that work.
Apparently we trigger the need to invoke equals/hashcode methods on managed entities just before the Session is attached to the BytecodeLazyAttributeInterceptor
Nathan Xu
Jan-Willem Gmelig Meyling
Moritz Becker
Sanne Grinovero
Andrea Boriero
Gavin King
Steve Ebersole
Falko Modler
Vishavjeet Thakur
Jezza
Guillaume Smet
Christian Beikov
Jay Paulsen
Oliver Breidenbach