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

[Sanne Grinovero]

2011/8/19 Hardy Ferentschik <hardy at hibernate.org>:
> Hi,
>
> I am not sure I understand the suggested path parameter. Taking the
> example from the forum:
>
>
> class A{
>    @IndexEmbedded(
>        paths={"d.one", "d.two"}
>     )
>    private C see;
> }
>
> class B{
>    @IndexEmbedded(
>        paths={"foo", "d.two"}
>    )
>    private C see;
> }
>
> class C{
>    @IndexEmbedded
>    private Collection<D> d;
>    @Field
>    private int foo;
> }
>
> class D{
>    @Field
>    int one;
>    @Field
>    int two;
> }
>
> what does it do? What fields get indexed for each entity?
>
> --Hardy

When indexing type A it would index only {"d.one", "d.two"} as read
from it's related C instance,
when indexing type B it would index only {"foo", "d.two"}, again read
from it's C instance.
C && D are indexed as usual, and I'm assuming all entities are marked
as @Indexed

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 like it because it makes the depth of recursion boundaries very
explicit, and also it can be shorted/longer on some specific paths,
forcing us to load only and nothing more than what is strictly
required to perform the specified fulltext queries, especially when
multiple entities are indexed both directly (as an @Indexed root) and
as a component of other entities.

Sanne