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