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

[Sanne Grinovero]

On 29 April 2014 11:28, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 29 Jan 2014, at 00:14, Sanne Grinovero <sanne at 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.

Right I got confused. I thought for a moment that we would encode the
primary identifier as a specific keyword, but there's no reason.
Forget what I said :)

>
>> 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.

Yes I mean we could never include it by default, and allow the
"includePath" to be the (only) way to include things.
Remember _includePath_ is additive to fields otherwise included via
@IndexedEmbedded _depth_, so it fits nicely for this role:

for non-indedex embedded elements it's of course nonsesense (as usual)
to specify an attribute which is lacking a @Field or similar option,
while for indexed types we implicitly apply one on the primary
identifier, this just needs to be selectable via _includePath_.

> 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.

I wouldn't do that now, but we can certainly leave this option open
for future evolution.

Cheers,
Sanne

>
> —Hardy