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

[Hardy Ferentschik]

On Mon, 22 Aug 2011 13:20:43 +0200, Sanne Grinovero <sanne at hibernate.org>  
wrote:

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

I don't quite get what you mean. You let the classbridge create its fields  
and
then add a path prefix to each field name?

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

Not sure if I like the surrogate Document idea. Maybe we can get rid of  
exposing any type
of "Document". The bridge could just return a Field(able).

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

How would a surrogate Document help in the dirty checking? Is this not an  
independent
problem?

--Hardy