Re: [hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded
Comments inline:
> This complicates things. First of all it means that the
"subPaths"
> property should now be named "includeSubPaths" instead, as opposing to
> "excludeSubPaths".
Yes, if 'excludeSubPaths' is provided, then 'subPaths' should be renamed
to 'includeSubPaths', for cleanliness/symmetry sake.
Or just 'include' and 'exclude'.
I feel we are becoming overly verbose in the API design (which is besides
this
particular issue)
> Also with such names I would expect the additional
> paths to work *in addition to* normal depth.
I think wasn't exact enough. I would expect 'includeSubPaths' to be
incompatible with both 'depth' and 'excludeSubPaths'. However, I would
expect 'depth' and 'excludeSubPaths' to be compatible. Which basically
says to index using the default approach, and only stop at max depth,
but exclude indexing of the paths specified.
given:
class C{
@IndexEmbedded
private Collection<D> d;
@Field
private int foo;
}
Illegal configuration: can't specify depth and includeSubPaths
simultaneously:
class A{
@IndexEmbedded(
includeSubPaths={"d.one", "d.two"}, depth=5
)
private C see;
}
Hopefully it would be understood that if only includeSubPaths is
provided, then the default depth is irrelevant and is explicitly
expressed per path.
My experience that is is not a good idea to change implicitly
ignore default values. In this case I would rather see an additional
enum parameter which allows the user to explicitly select the embedding
mode (BY_DEPTH, BY_PATH) or maybe introduce a new annotation @IndexSubPath
I think the complex option you thought I was implying was a mixed bag
approach. Which I'm not advocating for. My only purpose for suggesting
the 'exclude' option is that if I have 100 properties I want to index
for a particular entity, then listing 100 properties explicitly in
'includeSubPaths' could be laborious(and some might think messy). Those
100 properties could be directly on the entity, or they could be through
associated entities. However, because of my desire to have those 100
properties, because of 'depth' I might end up with 1000 values
indexed(mostly waste and potentially costly). In that case maybe those
900 other values come from a particular unused path, or a path I can
prune a bit through via 'excludeSubPaths'.
One thing worth mentioning is that generally the index size is not a big
problem
and we used to say that from a query point of view you have more
flexibility
if all properties are indexed (compared to limiting yourself already at
index
time to what you can search).
--Hardy