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

[Hardy Ferentschik]

On 11 Jan 2013, at 5:14 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> 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.

Could you post the code on how this looks like? I would like to the see the code
for such a value holder and the class bridge implementation.

> 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.

Any ideas yet on how this is supposed to look like? If you are moving away from
types and their properties, are you basically suggesting to offer an API to configure 
document fields directly? Or to put it another way, is the idea something similar to
the SOLR schema, but instead of XML we are using some sort of configuration DSL?

What is the result of queries in a non entity centric approach? Just field values? Returned
as object arrays?

>  In particular what seems to be
> troublesome is to implement multiple "user types" using the same type
> (java type) as value holders:

Again an example would be great.

> 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.

What do you mean with internal contract? Do you mean for example to key the EntityIndexBindings in 
ImmutableSearchFactory against their fully qualified name instead of the class instance?

Thinking about versions a bit more? Do we really want to do everything in Search 5? It becomes more
and more of an epic, fix everything release. Would it not be better to do the Lucene 4 migration first and
do a Search 5 release. Then we can do the "dynamic entities" suff in a 5.x or even 6 release. 
As far as I can tell we are having problems breaking down the work for the Lucene migration. Adding 
more moving parts will only make it worse imo.

--Hardy