On Mon, 22 Aug 2011 13:20:43 +0200, Sanne Grinovero <sa...@hibernate.org> wrote:
> 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. 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
