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

[Zach Kurey]

On Aug 30, 2011, at 10:47 AM, Sanne Grinovero wrote:

> I'm not 100% convinced but please go ahead and create a JIRA. There
> are definitely good improvements to take out of this thread, we can
> flesh out the details on JIRA or after a proof of concept patch.
> 
> My doubts is that I don't like adding an alternative to
> @IndexedEmbedded which has the same functionality;
> instead of creating a new one we could add an array of @IndexPaths to
> the @IndexedEmbedded (to be interpreted as additional paths), but I'd

Maybe there is some confusion about what I was proposing.  The idea is not to have 'additional paths'.  Instead the intent is to explicitly state that hibernate search should index 'only these paths' from the property it is declared on onward.  Which is why I think its conflicting to put @IndexPaths in @IndexEmbedded, since it essentially overrides/disables depth entirely(at least that is what I'd want it to do).  Each path has an explicit depth and if a particular path is > depth, I'd expect the path depth to be honored.

> prefer the string in this case just because I would expect to use this
> often, and typing an array of annotations as a parameter of another
> annotation is just ugly :)

I don't have a strong opinion here.  @IndexPaths(paths={"a", "b.c"}) is fine with me.  

> But a part from my taste, I'm not against this, the feature looks very
> good and useful, so let's open the issue and see if we get better
> ideas while implementing it.

K.  I'll open a ticket, and will be pretty explicit with a few examples, and what I'd expect to appear in the index.  

Thanks for considering the idea.  If it gets implemented it will be a really great tool to control indexing performance.

ZK