> While I'm obviously not so excited about the exclusions idea, maybe
> I'm overseeing a very useful case; is there a compelling reason to
> want that, enough to justify the added complexity? I'm not so much
> concerned about our code complexity (which might be an issue too) but
> more about the thinking process one must apply to use it.

I'm starting to regret proposing excludes...  One potential issue is that is 
that if excludes isn't available, then whenever someone decides to add paths, 
on app upgrades they will have to re-index everything.  Not a big deal for us 
since we do that periodically anyway, but not sure how that impacts other folks 
from an app maintenance point of view.  The excludes helps in that you can add 
searches for fields already indexed by a previous version of your app.  Then if 
you discover something is a performance problem and is not needed, you can 
prune it off to cause future app versions to not index that path anymore.

> Proposal:
> we add an array of @IndexedPaths to @IndexedEmbedded; depth remains
> the same, so for example
> 
> @IndexedEmbedded(depth = 1, paths=
>        {@IndexedSubPath("livingAddress.countryCode"),
>        @IndexedSubPath("bornPlace.countryCode")})
> private Person ownedBy;

I don't see how depth and paths are compatible at the same time?  It doesn't 
make sense to specify depth=0, depth=1, etc, when each path clearly has an 
explicit depth and depth will just be ignored.  Unless you are proposing depth 
and the paths somehow interact, but again, that seems confusing to have the 
potential to specify paths deeper than depth, or not as deep.

I think I'd go with where I left off in my last message with a proposal that 
looks more like:

Option 1:  Explicit inclusion only
@IndexPaths(
        paths={
            @IndexPath("a.b.c"),
            @IndexPath("d.e")
        }
)
private SomeType type;


Option 2:  Prune
@IndexEmbedded( 
    depth = N, 
    excludes={ 
        @ExcludeSubPath{"a.b.c"}, 
        @ExcludeSubPath{"d.e"}
     }
)
private SomeType type;

@ExcludeSubPath, @IndexPaths, @IndexPath, all leave room for potential 
expansion of configuration;  like if you wanted a different FieldBridge for 
path leafs... but pretend I didn't say that.  = P

I would be ecstatic if just @IndexPaths was added in the near future.  It would 
be cleanly separated from @IndexEmbedded and potential for confusion around 
depth.  Then if the community desires it, or makes some noise about the lack of 
the prune/exclude option, that can be added later with no impact to the 
@IndexPaths approach.

Would that reign in the concern for trying to do to much at first?  I think 
this is still 100% in line with the spirit of the original suggestion and 
results in the same indexing behavior.

Zach


_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to