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