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