Re: [hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded
On Mon, 22 Aug 2011 12:58:00 +0200, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
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
Now I get it. We are only talking about which fields get included. I
somehow
over-interpreted and thought you can also change how the fields are indexed
(different field configuration from within @IndexedEmbedded).
If we are just talking about field inclusion I think this approach is
reasonable.
I assume 'paths' would be optional and if not specified the current
approach
applies, right?
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.
That the other thing. Wouldn't you expect the path being the field names?
I bet you
we go for this syntax we get heaps of questions about the search not
working simply
because they search for the wrong field name.
--Hardy