Hmm - I looked at Spans more carefully, and it appears as if your idea
about a "fake" Query (some kind of SpanAllQuery would be called for)
would work well, and would probably be much simpler to implement. It
wouldn't preclude the kind of optimization I was talking about either,
but I don't kn
I think what I have in mind would be purely an artifact of the parser; a
term that would always be optimized away, either vanishing or gobbling
up the whole query. So if you had n(A,*), you would just get "A". If
you had and(A, not(*)) (is that the surround syntax for not?) you would
get not
Hi Mike: wheres for the normal queryparser this Query doesn't consult
the positions file and is trivial, how would such a query be
implemented for the surround parser? As a single span that matches all
positions for the whole document? Maybe it could be a "fake span" for
each document of 0 ... Inte
No, that doesn't work either - it works for the lucene query parser, but
not for the *surround* query parser, which I'm using because it has a
syntax for span queries.
On 5/6/2012 6:10 PM, Vladimir Gubarkov wrote:
Do you mean
*:*
?
On Mon, May 7, 2012 at 1:26 AM, Mike Sokolov wrote:
does
Do you mean
*:*
?
On Mon, May 7, 2012 at 1:26 AM, Mike Sokolov wrote:
> does anybody know how to express a MatchAllDocsQuery in surround query
> parser language? I've tried
>
> *
>
> and()
>
> but those don't parse. I looked at the grammar and I don't think there is a
> way. Please let us al
