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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to