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

[Hardy Ferentschik]

On 29 Jan 2014, at 15:24, Sanne Grinovero <sanne at hibernate.org> wrote:

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

Nope, the code is quite explicit. It contains a if/else statement checking whether 
we are processing the root entity and in the else part the comment says:
“// component should index their document id”

This is also not just an outcome of the metadata refactoring, since this if statement 
and comment also has been there in the DocumentBuilder code [1] 

So it has been an explicit choice at some point of time.

> - API wise it's much more complex to express the request-for-removal
> than to simply add it to includePath when needed

The question is also about a consistent behaviour across all use cases. Sure, 
we can add the id via the include path, but what I want to make sure that our implementation
makes sense in all cases and we have a comprehensible solution for users. 
So, I guess you are saying here, that the document id is just not a regular field. 

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

Interesting. Do you have a pointer to this functionality?

> We should aim at supporting it

Sounds good.

> Am I missing some strong use case which needs this, for which
> explicitly listing it on includePath is too annoying?

As said, it needs to make sense as a whole. 

> 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

I want to address HSEARCH-183 as well, just not sure your proposal is a 
requirement for that.

I was hoping HSEARCH-1494 would be an easy one, but it seems this goes much deeper ;-)

—Hardy

[1] https://github.com/hibernate/hibernate-search/blob/4.1/hibernate-search-engine/src/main/java/org/hibernate/search/engine/spi/DocumentBuilderIndexedEntity.java#L276