Re: [hibernate-dev] [Search] proposing an alternative to depth in @IndexedEmbedded
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=
{(a)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