sebersole

	@TestFactory
	public final List<DynamicNode> generateNodes() throws Exception {
		final Class<? extends EnversBaseTest> testClass = getClass();
		final List<DynamicNode> nodes = new ArrayList<>();

		final List<Method> testMethods = findMethods( testClass, method -> method.isAnnotationPresent( EnversTest.class ) );
		final List<Method> beforeEachMethods = findMethods( testClass, method -> method.isAnnotationPresent( EnversBeforeEach.class ) );
		final List<Method> afterEachMethods = findMethods( testClass, method -> method.isAnnotationPresent( EnversAfterEach.class ) );

sebersole

@Entity(...)
class EpisodePerson {

  @EmbeddedId
  Id id;
  @Enumerated
  EpisodeRole episodeRole;

  Episode getEpisode() {
    return getId().getEpisode();

sebersole

package org.hibernate.boot.jdbc.spi;

import org.hibernate.engine.jdbc.env.spi.ExtractedDatabaseMetaData;
import org.hibernate.engine.jdbc.dialect.spi.DialectResolutionInfo;

public interface DatabaseInformation extends ExtractedDatabaseMetaData, DialectResolutionInfo {
}

sebersole

	interface UpdateHandler {

		// todo (6.0) : Ideally I think the best option is for this delegate to just handle execution of the "entire SQM delete"
		//		i.e. the single HQL that needs to get split into multiple SQL operations...
		//
		//		something like:

		/**
		 * Execute the multi-table update indicated by the SQM AST passed in when this

sebersole

interface EntityPersister ... {
  
	// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	// Design a "Queryable"-like contract for asking the persister to augment
	// a org.hibernate.sql.exec.spi.JdbcOperation.
	//
	// One caveat to this is that currently JdbcOperation exposes the SQL String
	// whereas it would be more effective to have this contract have access to the
	// SQL AST for augmentation.  Either have JdbcOperation expose SQL AST, or
	// have this contract take an "in-flight" view of the JdbcOperation.

sebersole

Active questions and todo list for 6.0

A list of work to do (and questions to be answered) with regard to ORM 6.0 and 6.x.

This categorization follows MoSCoW paradigm.

Related major Jira issues

• HHH-10954 - Integrate SQM into upstream ORM

sebersole

package org.hibernate.persister.exec.spi;

public interface CollectionLoader extends Loader {
	// todo (6.0) - any (additional) Options info?
	
	interface Options {
	}

	List load(Serializable key, SharedSessionContractImplementor session, Options options);
}

sebersole

+ /home/jenkins/jdk-9-ea+155/bin/java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+155)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+155, mixed mode)
+ ./gradlew --stacktrace clean test
FAILURE: Build failed with an exception.

* What went wrong:
java.lang.ExceptionInInitializerError (no error message)

sebersole

Type system

SQM defines multiple "layers" to its type system. The lowest level is called SqmDomainType. The higher-level concept is called SqmExpressableType (which is a DomainTypeExporter which means it exposes a SqmDomainType).

The SqmDomainType is more-or-less akin to the Java type - on the ORM side, it actually relates to the org.hibernate.type.spi.Type contract. SqmDomainType is further categorized into:

• SqmDomainTypeBasic - a basic value

sebersole

java.lang.ClassNotFoundException: org.hibernate.proxy.pojo.bytebuddy.ProxyObject not found by org.hibernate.envers [99]

	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)
	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)