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

[Sanne Grinovero]

2011/8/22 Zach Kurey <pushedbytime at gmail.com>:
> 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:

Hi Zach, welcome to this very interesting mailing list.

>
>> 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.

agreed then.

>> 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.

Yes I agree on this, and think this is what Emmanuel meant too. I
wouldn't expect - as a user - to be able to mix the two, unless the
fieldbridge/classbridge is on a leaf of the path.

> 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.

This complicates things. First of all it means that the "subPaths"
property should now be named "includeSubPaths" instead, as opposing to
"excludeSubPaths". Also with such names I would expect the additional
paths to work *in addition to* normal depth.
So to implement your original suggestion we should have thought of a
mapping algorithm which would use either the _depth_ approach or the
_subPaths_ approach, but you say that in practice you would apply them
both?
In this case if I wanted to use the subPaths strategy only I should
use depth=0 and then add what I want to add? Just checking if we're on
the same page.

> 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.

Do you have a great example to support the more complex option? We
have to start somewhere, but the property names should be final and
the meaning should not change in future if we then want to add the
exclusions in future.

Sanne