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 <ha...@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
