2011/8/22 Emmanuel Bernard <emman...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
