> 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
