I think the original proposal was great, but also that we're now
pushing it to accomplish too much.
This feature as the potential to be *brilliant* but it must be
striking simple to both understand and use.
So what I like of the original concept, is that people using it will
focus on what they need starting from the concept of query, instead of
from the mapping: the mapping is a way to enable the queries, and the
queries are your goal.
When I'm coding, I know which Query I'll need to implement my feature,
and usually I will adjust index mapping consequentially; currently
when using @IndexedEmbedded on complex object graphs I might need to
draw a sketch to visualize the graph and define a proper depth (and as
you say I often ended up with custom ClassBridges to get better
control on objects loading).
So IMO the goal should be that starting from a well defined concept of
the FullTextQuery I'm going to need, I'm able to define the mapping in
a straight-forward form (and optimal, performance wise) to satisfy
these queries.
I think we can achieve this, but to be explicit with the mapping from
the queries I won't need the exclusion feature. I understand that it
might save some lines of code, but it will make my design process more
complex as I'll have to think if I'll get my desired mapping easier
with depth N and remove some paths, or depth N-1 and add some paths...
I'd prefer to have no options and keep it simple:
- if the developer is not sure yet about which fields he'll need next
day, he should set a reasonably high depth and don't bother about the
paths yet.
- when requirements have settled down, and it's time for performance
tuning, he'll be able to lower the defined depth values replacing them
with explicit paths. This step should be easy: set all depths to zero,
add the paths you think you're using, run tests, repeat until all
queries are satisfied.
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;
Or just
@IndexedEmbedded(depth = 1, paths={"livingAddress.countryCode",
"bornPlace.countryCode"})
private Person ownedBy;
I like the second more for it's shorter to write, but the first one
can be extended later. Let's go by steps and ignore the "paths" name
for now.
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.
Regards,
Sanne
2011/8/25 Zach Kurey <pushedbyt...@gmail.com>:
>
> On Aug 25, 2011, at 9:31 AM, Hardy Ferentschik wrote:
>
>> It still conflicts with the actual default value of depth and that there is
>> no explicit way to say that it is ignored. I don't think "it seems clear"
>> is a good enough reason.
>
> That's reasonable. If everything is left in IndexEmbedded you are right that
> it is basically mixing two different approaches into one annotation. The
> only other option I could think of is having an autoConfig attribute vs. an
> explicitConfig on IndexEmbedded. But that would require depth be moved into
> an 'autoConfig' annotation, which would not be desirable.
>
>> Yes, one of these alternatives. Maybe the "one new 'exclude' attribute in
>> IndexEmbedded and one new annotation for IndexSubPaths"
>
> That seems like the best fit, at the moment, as it eliminates any ambiguity.
>
> Zach
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
