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

[Sanne Grinovero]

On 29 April 2014 13:49, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> On Tue, Apr 29, 2014 at 1:45 PM, Hardy Ferentschik <hardy at hibernate.org> wrote:
>>> 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.
>
> I think we should keep the id with the default @IndexedEmbedded. It
> was weird to include the id when the includePath didn't ask for it but
> it would be weird to not include the id with the default
> @IndexedEmbedded.

It's not an indexed field, I don't think it was ever meant to be in
the index but rather a side effect of our recursion.. as we obviously
need the id of the root element.

I'm sure there are some good use cases for it, but here are my reasons
to prefer the field to be removed by default:
- API wise it's much more complex to express the request-for-removal
than to simply add it to includePath when needed
- Lucene4 includes a special payload encoding for "id like fields"
which has lots of benefits, with the one drawback that it has to be
unique per document. We should aim at supporting it, but embedded
collections would violate the uniqueness of the field instance in the
Document, so force us to actually encode this case in a different
way.. I guess we could explore it but encoding consistency becomes
puzzling.
- Index size matters a lot on query performance (especially on native
IO buffers), and what most affects index size is stored Fields.. like
ID. I think most people will have no use for this id field and will
probably not notice this additional optimisation opportunity.

Am I missing some strong use case which needs this, for which
explicitly listing it on includePath is too annoying?
Also by simply removing it I hope to give some more control back to
user (as we'll obviously honour any bridge/@Field annotation), as this
id-indexing behaviour has caused other related discussions:
HSEARCH-183

Sanne

>
> --
> Guillaume