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

[Hardy Ferentschik]

On Mon, 22 Aug 2011 12:58:00 +0200, Sanne Grinovero <sanne at hibernate.org>  
wrote:

> 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

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