Rework ElasticSearchBridgeProvider integration to not affect non-ES indexing

Description

The ElasticSearchBridgeProvider implementation essentially overrides the indexing format of some types, but this means that merely having the implementation on the classpath will affect the format of other indexes.

On top of that, we should also still allow running some indexes on ES and some other indexes using the plain Lucene integration.

Environment

None

Activity

Show:
Guillaume Smet
February 24, 2016, 3:16 PM

So... I took a look at this. Mainly by trying to reorganize the SearchIntegratorBuilder.initDocumentBuilders to have the IndexManagers information earlier and exploit them in the fieldBridge metadata construction.

While extracting the IndexManager configuration and exploiting it at initialization seems doable for root entities, doing so for contained entities is not feasible as they can potentially be contained in 2 entities which might be using 2 different IndexManagers. And we won't know it except at runtime.

Did I miss something?

Sanne Grinovero
February 24, 2016, 3:23 PM

Good point.

The solution would be to have a separate instance of org.hibernate.search.engine.spi.DocumentBuilderContainedEntity for each root point. For example if "Author" is embedded in both entities A and B, you'd have a different builder instance for A.author and B.author; at this point each instance of DocumentBuilderContainedEntity could be flagged as "belongs to indexmanager X" and hold the information you need.

Sanne Grinovero
March 13, 2016, 10:08 PM

See also commit id 332f702 : when fixing this, we need to re-enable the MassIndexingTimeoutIT integration test.

Fixed

Assignee

Guillaume Smet

Reporter

Sanne Grinovero

Labels

None

Suitable for new contributors

None

Feedback Requested

None

Components

Fix versions

Priority

Blocker
Configure