On Mon, 22 Aug 2011 12:58:00 +0200, Sanne Grinovero <sa...@hibernate.org>
wrote:
> 2011/8/19 Hardy Ferentschik <ha...@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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
