Re: [hibernate-dev] [Search] Index embedded and id property of embedded entity
On 29 Jan 2014, at 00:14, Sanne Grinovero <sanne(a)hibernate.org> wrote:
I'd avoid a new configuration element.
+1 Sure, that would be best.
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.
I agree. I don’t think there is a good reason for including the id of the embedded
entity by default, especially since it leads to potential problems as described in
HSEARCH-1494.
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.
Sure. My questions was basically about how we allow this type of id inclusion.
Now the complexity is I guess to define what it means to
"explicitly
flag the need for it”;
exactly :-)
I think @IndexedEmbedded should not include it
by default, unless explicitly listed via the _includePaths_ attribute.
include paths is one use case, but there is also the default @IndexedEmbedded behaviour
which includes all indexed field (including the id atm).
Question: would we still interpret the literal "id" as a
keyword
pointing to whatever getter is the primary key of the embedded object?
Why still? We don’t do this at the moment afaict. Our examples and tests just use ‘id’
all the time.
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.
I am not following you here. What do you mean? Also you seem to just target the
includePath case.
Another thought would be to make this a global configuration option. Something like
hibernate.search.embeddedindexing.include_id_property. Per default the flag would be
false, but
could be set to true. Obviously this is a quite coarse solution.
—Hardy