Re: [hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded
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