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

[Zach Kurey]

> 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