Skip to content

Latest commit

 

History

History
202 lines (146 loc) · 5.97 KB

release-announcement.adoc

File metadata and controls

202 lines (146 loc) · 5.97 KB

Hibernate 6.6.0.Alpha1

Jakarta Data

Hibernate 6.6 includes a complete implementation of the current Jakarta Data 1.0 Release Candidate. As discussed here, our implementation:

  • is based on compile-time code generation via an annotation processor, enabling unprecedented compile-time type safety, and

  • is backed by Hibernate’s StatelessSession, which has been enhanced especially to meet the needs of Jakarta Data.

This implementation already passes the Jakarta Data TCK, and we have a request for certification pending.

To make use of Hibernate Data Repositories, you’ll need to depend on:

  • our annotation processor, hibernate-jpamodelgen, and

  • the Jakarta Data API, `jakarta.data-api.

For example, in Gradle:

implementation 'jakarta.data:jakarta.data-api:1.0.0-RC1'
implementation 'org.hibernate.orm:hibernate-core:6.6.0.Alpha1'

annotationProcessor 'org.hibernate.orm:hibernate-jpamodelgen:6.6.0.Alpha1'

For more information, please see the brand-new Hibernate Data Repositories documentation.

@ConcreteProxy

6.6 also provides a new @ConcreteProxy annotation intended as an improved replacement for the deprecated @Proxy and @LazyToOne annotations. Indicates that lazy references should be instantiated as the concrete type rather than the referenced type.

Consider the following model and data

@ConcreteProxy
@Entity
@Inheritance
class Payment { ... }

@Entity
class CardPayment extends Payment { ... }

session1.persist( new CardPayment( 1, ... ) );

As a simple example -

Payment loaded = session2.getReference( Payment.class, 1 );

Historically, Hibernate would create a lazy proxy for loaded of type Payment. Attempts to cast that reference to CardPayment would result in a casting error. @ConcreteProxy forces Hibernate to resolve the actual, concrete type and create a proxy of that type instead -

CardPayment loaded = (CardPayment) session2.getReference( Payment.class, 1 );
Important
Hibernate will try a number of different ways to determine the concrete type, but may ultimately have to fall back to hitting the database which might have an effect on performance.

This feature works with both Hibernate’s legacy proxy-based laziness and the newer bytecode enhancement laziness.

Extended Array support

ORM 6.6 adds support for mapping arrays of embeddable aggregate types e.g.

@Entity
class MyEntity {
	List<MyEmbeddable> embeddableAggregateList;
}

@Struct
@Embeddable
class MyEmbeddable { ... }

Syntax sugar for array functions

Plenty of syntax sugar for array operations was added:

Function Syntax sugar

array(1, 2)

[1, 2]

Shorthand bracket syntax for array construction

array_slice(array, 1, 2)

array[1:2]

Shorthand bracket syntax for array slicing

array_length(array)

length(array)

Overload length function with array_length semantics on array input

array_position(array, element)

position(element in array)

Overload position function with array_position semantics on array input

array_to_string(array, ',', 'null')

cast(array as String)

Support casting array to string

array_contains(array, element)

array contains element or element in array

Contains predicate for containment check

array_includes(array, array)

array includes subArray

Predicate to for subset checking

array_intersects(array, array(1, 2))

array intersects [1, 2]

Overlaps predicate for overlaps check

Syntax sugar for string functions

The bracket syntax can now also be used for string typed expressions to select a single character by index, or obtain a substring by start and end index.

stringPath[2] is syntax sugar for substring(stringPath, 2, 1) and returns a Character. stringPath[2:3] is syntax sugar for substring(stringPath, 2, 3-2+1), where 3-2+1 is the expression to determine the desired string length.

Embeddable Inheritance

Another new feature of this version is discriminator-based inheritance for @Embeddable types. An @Embeddable class may be extended by other @Embeddable classes, in which case the @Embedded properties using that type will rely on an additional discriminator column to store information about the composite value’s subtype.

When retrieving the inherited embedded property, Hibernate will read the discriminator value and instantiate the correct @Embeddable subtype with its corresponding properties.

For example, a mapping like this:

@Embeddable
@DiscriminatorValue( "parent" )
@DiscriminatorColumn( name = "embeddable_type" )
class ParentEmbeddable implements Serializable {
	private String parentProp;
	// ...
}

@Embeddable
@DiscriminatorValue( "child_one" )
class ChildOneEmbeddable extends ParentEmbeddable {
	private Integer childOneProp;
	// ...
}

@Entity
class TestEntity {
	@Embedded
	private ParentEmbeddable embeddable;
	// ...
}

Will result in the following table structure:

create table TestEntity (
    -- ...
    embeddable_type varchar(31) not null,
    parentProp varchar(255),
    childOneProp integer,
    -- ...
)

For more detailed information please refer to the Embeddable inheritance user guide chapter.