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

[Hardy Ferentschik]

Where are we at in this discussion?

I think we basically have to main proposals.

#1 Don’t include the embedded id per default. If @IndexEmbedded is used via the depth parameter there is no way to include the embedded id.
     In order to include the id you would need to use includePaths. depth and includePaths can be used in combination, so something like this 
     is possible @IndexedEmbedded( depth = 1, includePaths = “foo.id” ). This will include all configured fields of the embedded entity, plus its id.
#2 Don’t include the embedded id per default, but have an additional flag on @IndexedEmbedded to include the embedded id. The default would be false.
    To include the id would be something like @IndexedEmbedded( depth = 1, includeEmbeddedId = true ) or 
    @IndexedEmbedded(  includePaths = {“foo.a”, “foo.b”, “foo.c”} , includeEmbeddedId = true ).

I think I favour #2 atm, since it seems more symmetric. 

On top of this we seem to agree that it is a good idea to set the default depth value of @IndexedEmbedded to 0. This avoids the change in default values,
when includePaths is used. As a side effect the default @IndexedEmbedded annotation becomes a no-op and should be treated as an invalid configuration.
The choice here is between:

#1 Log warning and move on
#2 Throw an exception due to invalid configuration

My choice would be #2 again.

Thoughts?

—Hardy



On 30 Jan 2014, at 20:19, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
>> 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. 
> 
> To clarify what bugs me is, that you are basically suggesting that the id can be included via
> include path, but can never be used via the depth approach. 
> 
> One option we have not discussed yet, is an additional method on @indexedEmbedded. 
> Something like includeEmbeddedId. Default would be false. If you set it to true, the id is
> included. It makes id inclusion orthogonal to depth and includePath.
> 
> —Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev