[hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded

[Hardy Ferentschik]

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