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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
