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

[Hardy Ferentschik]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev