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

[Gunnar Morling]

Sanne,

Is there any news on where we stand with this?

I saw you discussed and moved some issues to HSEARCH 5; Does that mean we
have everything in place now for the ISPN use case? I'd have assumed at
least making the OBJECT_CLASS (HSEARCH-1402) field user-writable would be
needed for restricting queries to specific "user types", but this one has
been moved to 5 as well.

Thanks,

--Gunnar



2013/9/20 Gunnar Morling <gunnar at hibernate.org>

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