On 06 May 2014, at 21:43, Hardy Ferentschik <hardy(a)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