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

[Zach Kurey]

Hi,

I was the poster on the forum that triggered this conversation.  Sanne suggested I jump onto the dev mailing list for this and future suggestions, so here I am.  I'm a developer in the San Francisco bay area.  I've been using hibernate search for about a year on a project I've been working on.  Primarily to eliminate lots of expensive joins, and leveraging wild carding, but not many other full text features(phonetic searching, stemming, etc)... yet.  In any case, back to the topic at hand:

> Maybe "path" should be named differently, "subpaths" ? Otherwise I'm
> tempted to expect that the prefix should have been included, like in
> {"see.d.one", "see.d.two"} but I wouldn't include the prefix as it
> complicates it quite more.


I think specifying 'see.d.one' is redundant, since the annotation is on the property 'see'.  I like the subPaths idea, it makes the lack of needing to specify 'see' more intuitive.

> That's an interesting idea. 
> It has some limitations like the inability to cover class level bridges but that might not be too bad.

It just may be my lack of use of class bridges, but I would think it may be reasonable they be ignored 'within' subPaths, but OK if a path terminates with a type that has a ClassBridge specified.  Even if a property along the path has a class level bridge, I'd expect it to not be invoked and that the specific path is still followed with the default indexing behavior.  Or at the very least that would be a straight forward starting point for the behavior.  

Another related suggestion, is that in many cases people may want fine grained control from an exclusion point of view.  I'm usually trying to target very specific fields to search on, but there are cases where I've needed a lot of things to be indexed and the default behavior has been quite nice from a development time savings perspective.  Even though its just a one time dev cost, it might be nice if folks could specify an 'excludeSubPaths' option as well.  Where the default behavior might work fine for them for 99% of what is being indexed, but a particular path is causing a problem and doesn't need to be indexed for a particular use case.

Still though, if I had to choose only one, specifying 'subPaths' would be a very nice explicit tool for only indexing what I actually need per use index use case.

Zach