[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth

Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth --------------------------------------------------------------------------------------------------------- Key: HSEARCH-886 URL: https://hibernate.onjira.com/browse/HSEARCH-886 Project: Hibernate Search Issue Type: New Feature Components: engine, mapping Reporter: Zach Kurey Assignee: Davide D'Alto Frequently its desirable to index a particular embedded type differently depending on the use case of the referencing type that is the primary subject being indexed. Additionally, depth in general causes many more paths to be included in a document than necessary for a particular index. This makes tuning of indexing to eliminate problem paths difficult, and sometimes impossible if a particular object model re-uses a lot of types. The proposal/improvement has already been discussed more in depth here: http://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg06548.html, and what follows reflects some of that discussion. As an example of how specific paths could be configured for indexing: @Indexed class A{ @IndexEmbedded( depth=0, @IndexPaths(paths={"d.one", "d.two"}) ) private C see; } @Indexed class B{ @IndexEmbedded( depth=0, @IndexPaths(paths={"foo"}) ) private C see; } class C{ @IndexEmbedded private Collection<D> d; @Field private int foo; } class D{ @Field int one; @Field int two; } Index A would contain: d.one, and d.two Index B would contain: foo, but would NOT contain anything from path 'd'. Perhaps indexing path 'd' has a performance impact that is desirable to eliminate for B, but acceptable or necessary for A. This ability would also help to eliminate the bloat of unnecessary fields in lucene documents; which may not itself be a performance problem, but leaves a lot of things to rule out when tracking down indexing issues(both performance or content). Lastly. To be clear, the above proposal(which really Sanne came up with in the email thread) does not conflict with depth. Here are some further examples of how depth may interact with explicit paths: @IndexEmbedded(depth=3, paths={"a.b.c.d.e"}) Says to index all paths up to depth 3, but additionally index path 'a.b.c.d.e'. @IndexEmbedded(depth=0, paths={"a.b.c.d.e"}) Says to only index path 'a.b.c.d.e' @IndexEmbedded( paths={"a.b.c.d.e"}) Default behavior, depth is unlimited, specifying a.b.c.d.e is redundant in this case.