[hibernate-dev] [Search] Index embedded and id property of embedded entity

[Sanne Grinovero]

Hi Hardy,
I'd avoid a new configuration element.

I think we should strive at keeping the index small by default unless
there is a strong usability penalty, and I don't think this is a big
one.
Some power users pointed out that there are use cases in which having
the _id_ field of embedded relations is useful, so we should still
allow to add it when someone explicitly flags the need for it.

Now the complexity is I guess to define what it means to "explicitly
flag the need for it"; I think @IndexedEmbedded should not include it
by default, unless explicitly listed via the _includePaths_ attribute.

Question: would we still interpret the literal "id" as a keyword
pointing to whatever getter is the primary key of the embedded object?
I'm inclined to seek for a property which has the name as listed in
_includePaths_, not giving the "id" literal a special treatment in
this case.

Sanne



On 28 April 2014 20:43, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> I started to look at HSEARCH-1494 [1] which deals with an unexpected exception is thrown when @IndexedEmbedded is used.
> Easiest to explain with an example:
>
> @Entity
> @Indexed
> public class A {
>         @Id
>         @GeneratedValue
>         private long id;
>
>         @OneToOne
>         @IndexedEmbedded
>         private B b;
> }
>
> @Entity
> public class B {
>         @Id
>         @GeneratedValue
>         private Timestamp id;
>
>         @Field
>         private String foo;
>
>         public Timestamp getId() {
>                 return id;
>         }
>
>         public String getFoo() {
>                 return foo;
>         }
> }
>
>
> A includes B via @IndexedEmbedded and is only interested in including the ‘foo’ field. However, atm we implicitly index B.id as well.
> In this particular case an exception is thrown, because we don’t know which field bridge to use for B.id.
>
> This also relates to HSEARCH-1092 [2], where the include path feature of @IndexedEmbedded is used. Even though the configured
> paths don’t include the ids, they are added which increases the index size unnecessarily (not really sure whether it really matters in practice).
>
> If we skip the implicit inclusion of id properties, the user will need to add an explicit @Field in case he wants to include an id property via indexed
> embedded. If the embedded entity itself is not indexed, I think this makes sense. But what if the embedded entity is indexed itself? Does it seem
> wrong in this case to specify an additional @Field? Do we need some additional configuration element?
>
> Thoughts?
>
> —Hardy
>
>
> [1] https://hibernate.atlassian.net/browse/HSEARCH-1494
> [2] https://hibernate.atlassian.net/browse/HSEARCH-1092
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev