Re: [hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded
2011/8/19 Hardy Ferentschik <hardy(a)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