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

Hardy Ferentschik hardy at hibernate.org
Tue Apr 29 07:45:37 EDT 2014


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

But this forces you to list all fields to include explicitly in case you want the id added, but otherwise are happy
to just use the default @IndexedEmbedded.

> Remember _includePath_ is additive to fields otherwise included via
> @IndexedEmbedded _depth_, so it fits nicely for this role:

Is that really true? AFAIK the includePath attribute changes the behaviour of the depth attribute.
Depth is ‘0’ per default if ‘includePath’ is used. So you would have to include the id via includePath
and also set the depth explicitly to something > 0. I also find it not intuitive that this means:
"index all embedded fields up to the given depth, plus the specified paths”. 
I never liked how we baked depth and includePath into the same annotation. A dedicated annotation would
have been more appropriate. 

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

I am just not sure, whether we easily can tell when processing the embedded entity whether it is indexed or not.
Obviously that is an implementation detail, but we might have to jump through some hoops here (might be wrong).

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

Ok.

—Hardy


More information about the hibernate-dev mailing list