(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 could set a very high position increment gap for multi-valued
: > fields (Analyzer#getPositionIncrementGap) and perform something
: > like Intervals.maxWidth(Intervals.unordered(...), pos_gap-1) ?
I'm assuming form your response that the issue here is really that you
want to *directly* support the syntax you mentioned...
: >> > > doc: field=["foo", "bar"]
: >> > > query: field:(foo AND bar)
...and identify *when* the parser encouters a "boolean" expresion
preceeded by the "fieldName:" syntax, and *then* treat thta special.
ie: this seems 100% like a query parser question, and not at all as a
"what does the query structure look like ater parsing" question.
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.
i *THINK* the crux of your question/problem is that -- from the point of
view of the QueryParserBase/BooleanQueryNodeBuilder, these 2 input strings
are treated identically by the time any "subclass" has a chance to do anything
interesting with them...
field:(foo AND bar)
field:foo AND field:bar
...so you can't for instance, build an Interval / sloppy Phrase query from
the first, while building a 2 clause boolean query from the second.
So maybe the "solution" (at least for the flexible parser ... IIUC, I
haven't used it much) would be for BooleanQueryNode to carry some metadata
indicating that there was a "fieldName:" prefix on it, so that the
BooleanQueryNodeBuilder can choose to use that information to do something
"special" if the "List<QueryNode> clauses" are all simple TermNodes (in
the same field)
?
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]