[hibernate-dev] Decoupling indexed types from their class definitions

[Sanne Grinovero]

Some other projects use Hibernate Search - specifically the engine
module - to bridge their domain model to a Lucene index and take
advantage of its high performance low-level integration with Lucene.
This is generally achieved by indexing a "valueholder" object which
has most logic to create a custom o.a.l.Document in a top level
@ClassBridge, or by using some custom FieldBridges, but has some
strong limitations and feels more like a hack.

In Hibernate Search 5.0 we will make this more flexible, so to move
away from an annotated-entities index engine only to make it easier to
index objects whose "schema" is more flexible than the contraints
imposed by the staticness of a compiled Java class.

We've discussed however to introduce some of these features right now
(in version 4.4), so that we can start exploring the direction
gradually and get some early feedback. In particular what seems to be
troublesome is to implement multiple "user types" using the same type
(java type) as valueholders: the trouble is to filter on the correct
user type where the Hibernate Search APIs expect - as basic filtering
strategy - a java Class instance, or simply to have the flexibility to
configure separate backends for each user type.

So this first refactoring [HSEARCH-1402] will be about moving the
*internal* contract - without changing public APIs - to use a
different identification than the current Class when we lookup for
indexing information for a specific indexed type.

Comments very welcome.

Sanne

- https://hibernate.atlassian.net/browse/HSEARCH-1379 Explicit support
for indexing free-form (dynamic) entities

- https://hibernate.atlassian.net/browse/HSEARCH-1402 Allow explicit
user control of ProjectionConstants.OBJECT_CLASS value during indexing

- https://hibernate.atlassian.net/browse/HSEARCH-1404 More flexibility
than just Class to identify indexing metadata