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

[Emmanuel Bernard]

On 06 May 2014, at 21:43, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 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 like #2 much better. It is too complex to ask of the user to understand how the combination of depth and includePaths work based on fairly arbitrary rules.
I thing the property should be named includeEmbeddedObjectsIds because embeddedId has a precise meaning in ORM.

One question in that case, what does this one do

    @IndexedEmbedded( includePath = { “foo.id” }, includeEmbeddedId=false //default )

I think we should honour includePath according to the additive rule mentioned earlier and the path of least surprise.

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

Is that really a good idea? As you guys said, @IndexedEmbedded becomes a (silently or not) broken mapping :(
It also means that the simplest @IE usage requires to understand depth and / or includePath.
I don’t like that at all. It makes things more complex than they should be for the simple case.

Emmanuel