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

[Gunnar Morling]

Hi,

I'm beginning to wonder which of these things we actually do need in 4.4 to
satisfy the requirements of ISPN remote queries. At the moment we have:

* the ability to index "user types" via one generic "value holder type"
using a smart class bridge which adds all the required fields; with
HSEARCH-1396 [1] we allow for passing bridge _instances_ to the engine
which e.g. enables to inject the user type configuration (which fields
required) into this class bridge by the client

* the ability to query the properties of a user type by allowing to specify
the bridges to be used for given fields (HSEARCH-1409 [2], PR is opened
[3]); In particular this allows to query against fields which are not
statically declared for the value holder type

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

I think this part is still missing. I'm wondering though whether it
couldn't be emulated "well enough" by making the
ProjectionConstants.OBJECT_CLASS field user-writable (as suggested with
HSEARCH-1402) and querying on this field? Together with the dynamic
sharding work from Hardy also the "separate backends for each user type"
part might be addressed by assigning each user type to a separate shard of
the value holder type's index.

If this is feasible, it would allow to stick to the class-based design for
the time being. This might help with limiting the number of changes
required to be delivered with 4.4 and focus on implementing the dynamic
entity feature properly in HSearch 5. Any thoughts?

--Gunnar

[1] https://hibernate.atlassian.net/browse/HSEARCH-1396
[2] https://hibernate.atlassian.net/browse/HSEARCH-1409
[3] https://github.com/hibernate/hibernate-search/pull/486


2013/9/11 Sanne Grinovero <sanne at hibernate.org>

> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>