Re: [hibernate-dev] Decoupling indexed types from their class definitions
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev