Carefully control how and when engine APIs are exposed in the ORM integration

Description

Follow-up on HSEARCH-1404: we've had some trouble making the transition to an engine that would accept indexed types that are not POJOs (for instance JSON objects), because:

  • this would require engine APIs (in particular) to be agnostic regarding the indexed type

  • and unfortunately, these APIs are exposed in the ORM module, where we definitely want all APIs to accept Class<?> as an indexed type identifier

The most obvious solution to our predicament would be to isolate the ORM APIs from the engine APIs as much as we can, adding wrappers that would perform the convertion between Class<?> and IndexedTypeIdenfitier as necessary.

There may be some shared APIs from time to time; I'm thinking of APIs such as the one mentioned in this comment, where everything after .query(Animal.class) could be shared between ORM and Engine.

Let's also keep in mind that other integrators of Hibernate Search - such as Infinispan - would benefit from the "POJO mapping via annotations" mode but will not want to depend on Hibernate ORM.
For this reasons the actual code reading from annotation mapping to build a schema, the object graph navigation code, etc.. should still be included in hibernate-search-engine (practical choice) or in a new separate module. This requirement suggest that the SPI will not be entirely removed.

Activity

Show:

Yoann Rodière April 25, 2018 at 10:02 AM

Resolved as part of the Search 6 proof of concept groundwork.

The APIs are now more "layered":

  • the engine exposes generic APIs that should work for any mapped type, be it POJOs, JSON, etc, because these APIs are focused on the index (they deal with indexes and index fields, not classes and object properties). See for instance SearchQueryResultDefinitionContext.

  • the mapper declares APIs that are closer to the mapped type. See for instance org.hibernate.search.v6poc.entity.pojo.mapping.PojoSearchManager#search(java.util.Collection<? extends java.lang.Class<? extends T>>)

  • in the case of POJO-based mappers, the actual mapper implementations can refine the APIs defined by the "abstract" POJO mapper. See for instance the ORM integration, where we override org.hibernate.search.v6poc.entity.pojo.mapping.PojoSearchManager#search(java.util.Collection<? extends java.lang.Class<? extends T>> to org.hibernate.search.v6poc.entity.orm.mapping.HibernateOrmSearchManager#search(java.util.Collection<? extends java.lang.Class<? extends T>>)

Fixed

Details

Assignee

Reporter

Components

Fix versions

Priority

Created June 9, 2017 at 8:26 AM
Updated November 28, 2018 at 3:43 PM
Resolved April 25, 2018 at 10:02 AM