[hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded

Sanne Grinovero sanne at hibernate.org
Mon Aug 22 07:20:43 EDT 2011


2011/8/22 Emmanuel Bernard <emmanuel at hibernate.org>:
> That's an interesting idea.
> It has some limitations like the inability to cover class level bridges but that might not be too bad.

Right. I think we should support entities having class level bridges
as @IndexedEmbedded, by prefixing whatever they want to add to the
index with the current prefix/navigation path, in a similar fashion of
what we do with MaskedProperty.

This implies removing direct access to the Document from the FieldBridge API
org.hibernate.search.bridge.FieldBridge.set(String, Object, Document,
LuceneOptions)

and have APIs write to a surrogate Document.

This is a radical change, and I wouldn't suggest it if it where for
this feature only, but we have found more reasons to introduce the
surrogate Document in the past:

 - Dirty checking optimizations would require a FieldBridge API change
to know which entity fields are being read (which might be dirty, or
unchanged)
 - To enable at some point - not necessarily for 4.0.0, but possibly
without breaking APIs in 4.x - the capability to perform Analysis
before sending the Document to the backends

This is one of the points we have on
http://community.jboss.org/wiki/PlansForHibernateSearch4
but of course it's not cast in stone, especially since I previously
thought we would need it for the Serialization API but Emmanuel proved
otherwise.

Sanne



More information about the hibernate-dev mailing list