[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