> If they try to use any other options then 'i' we throow a ParseException
+1. Complex-syntax parsers should throw (human-palatable) exceptions
on syntax errors. A lenient, "naive user" query parser should be
separate and accept a very, very
rudimentary query syntax (so that there are literally no
Hi Chris,
> Because if you can adjust your parser syntax, this literallyly just
> becomes: ' field:"foo bar"~N ' ... where N is the positionIncrementGap
> on your analyzer ... OR ... ' field:"foo bar" ' ... if you call
> setPhraseSlop on your QueryParser.
Yes - correct. This would be equivale
(caveat: i don't ever really understand what Intervals at hte lucene
feature set stage)
: Yup - similar to what Alan suggested. I'd have to rewrite the (general
: text-to-query) query parser to only use intervals though. Still
: thinking about possible approaches to this.
...
: > You co
> It would be great to run all the tests every time, but clearly that is
too expensive.
The reference_impl branch requires around 30 seconds to run all solr-core
tests. That's where we should all put our collective efforts.
Also, I have reservations against docker based tests blocking PRs. If I
do
: And as I understand it, current behavior is the silent misinterpretation.
: To me, the failure to require a space after the regex (and either not
: become a regex in that case or complain about invalid regex) might be
: considered a bug...
I would agree ...
: >> However, today people can search
Thanks Alan. I don't think my foo is strong enough to dive deep into
implementing intervals... yet. :) I'll try to clean up what's active
on my plate and maybe later I'll return to this.
Dawid
On Thu, Sep 17, 2020 at 3:53 PM Alan Woodward wrote:
>
> I think you need a sort of ‘ordered atLeast’
I like this idea. The only downside is that folks will tend to think
it's a full Java Pattern and try other options. :)
On Thu, Sep 17, 2020 at 9:09 PM Steve Rowe wrote:
>
> You could avoid (some of?) these problems by supporting /(?i)foo/ instead of
> /foo/i
>
> --
> Steve
>
> On Sep 17, 2020,
That's a much better idea, I like it. It's basically what Javas regex parser in
the Pattern class also does.
If we do this we won't even need a syntax change.
Uwe
Am September 17, 2020 7:09:18 PM UTC schrieb Steve Rowe :
>You could avoid (some of?) these problems by supporting /(?i)foo/
>instea
You could avoid (some of?) these problems by supporting /(?i)foo/ instead of
/foo/i
--
Steve
> On Sep 17, 2020, at 1:55 PM, Gus Heck wrote:
>
> And as I understand it, current behavior is the silent misinterpretation. To
> me, the failure to require a space after the regex (and either not bec
And as I understand it, current behavior is the silent misinterpretation.
To me, the failure to require a space after the regex (and either not
become a regex in that case or complain about invalid regex) might be
considered a bug...
On Thu, Sep 17, 2020 at 9:30 AM Mark Harwood wrote:
> I think
Thought I'd make this a thread instead of a discussion on a single JIRA
ticket.
Currently we have gradle precommit run on PRs for master, which is very
useful and gives people confidence in approving PRs. But precommit is
obviously not the only thing we care about before committing. It would be
gr
I think you need a sort of ‘ordered atLeast’ here. Currently atLeast() is a
mixture of a disjunction and an unordered interval, it should be possible to
add something that adds additional constraints to the sets that it finds. I
think you’d need to write some code though, I can’t see a way of
I think the decision comes down to choosing between silent
(mis)interpratations of ambiguous queries or noisy failures..
On Thu, Sep 17, 2020 at 1:55 PM Uwe Schindler wrote:
> Hi,
>
>
>
> My idea would have been not to bee too strict and instead only detect it
> as a regex if its separated. So /
Hmm... Is there any way to express a query for a phrase-like sequence of tokens:
a b c d
but with potential "holes" (one or more terms missing):
- b c d
a - c d
a b - d
...
I've experimented with ordered(term("a"), term(b), ...), gaps and
atLeast but I can't get it to work. I could expand terms
Hi,
My idea would have been not to bee too strict and instead only detect it as a
regex if its separated. So /foo/bar and /foo/iphone would both go through and
ignoring the regex, only ‘/foo/ bar’ or ‘/foo/I phone’ would interpret the
first token as regex.
That’s just my idea, not sure i
Hi,
this ongoing build failures is a bug in the "warnings-ng" Jenkins plugin, which
was updated yesterday. I reverted to previous version, as instructed by the
project maintainer:
https://issues.jenkins-ci.org/browse/JENKINS-63659
Sorry for that,
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357
16 matches
Mail list logo
