Re: [hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded
On Mon, 22 Aug 2011 13:20:43 +0200, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
2011/8/22 Emmanuel Bernard <emmanuel(a)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