Re: [hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded
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
On Fri, 19 Aug 2011 11:07:07 +0200, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
Hi all,
I just noticed this proposal on the forum:
https://forum.hibernate.org/viewtopic.php?f=9&t=1012303
I think it's very reasonable, as people don't usually care for the
depth but for the fields they can or can not search.
In addition to a better API, for the sake of the Query Parser
something like that will be very useful: I'll need to be able to
figure out how to map the entities to the index starting from the
known (named) queries.
Also this should play nicely with
HSEARCH-638 - Limit graph traversal by @ContainedIn to the minimum
required path
(optimistically scheduled for the next alpha)
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev