Sticking to my contextual argument I would use 'matching'
On Thu, 10 Jun 2010 12:31:49 +0200, Emmanuel Bernard
wrote:
>> Even though I understand the conceptional difference between 'matching'
>> and 'sentence' when it comes to a phrase
>> query, but is there really a need for two different
On 10 juin 2010, at 12:25, Hardy Ferentschik wrote:
> Even though I understand the conceptional difference between 'matching' and
> 'sentence' when it comes to a phrase
> query, but is there really a need for two different methods? From the context
> I can always see whether I have a
> keyword(
I like 'matching' better than 'whichMatches', because the latter is a real
mouthful to say at least for me.
I guess for me that means 1.
Even though I understand the conceptional difference between 'matching'
and 'sentence' when it comes to a phrase
query, but is there really a need for two di
Please vote for:
- 1. or 2.
- matching vs whichMatches vs match
- matchingSentence vs basedOnSentence
- exclude vs excludeLimit
- if 2. findInRange vs findWithinRange
If you vote for 2., does the boolean query structural difference bother you?
1.
monthQb
.phrase()
.withSlo
withSlop instead of slop looks like a good improvement (same for the fuzzy
params etc)
I have not used phraseQuery() because what you get is not a query compared to
createQuery(). That's why I think phrase is better than phraseQuery. But I'm
open to other options.
matching vs sentence etc
Ther
It's looking very good; I'll seek a couple of hours this weekend to
actually try it for real.
I don't think it need changes, but if you seek for in depth-criticism
I might add some additional fuel:
I'm not 100% convinced about the use of "matching()" as method name,
it confuses me a bit. This migh
Looks fine to me looking at the examples. I haven't tried myself writing
my own queries though
to see the full potential.
On Wed, 02 Jun 2010 18:00:20 +0200, Emmanuel Bernard
wrote:
> Guys,
> I'me now done with the level of abstraction and fluidity I wanted out of
> the query DSL. Please revie
Guys,
I'me now done with the level of abstraction and fluidity I wanted out of the
query DSL. Please review before we push that out. Key features:
- fluent API
- use the field bridge system: type is passed, not raw string
- use the analyzer transparently
- simple use case simple, complex use
