Hello,
I've attempted to figure this out from reading the documentation but
without much luck. I looked for a comprehensive query syntax specification
(e.g., with BNF and a list of operator semantics) but I'm unable to find
such a document (does such a thing exist? or is the syntax too much of a
On Sat, Sep 27, 2014 at 2:52 PM, White, Bill bwh...@ptfs.com wrote:
Hello,
I've attempted to figure this out from reading the documentation but
without much luck. I looked for a comprehensive query syntax specification
(e.g., with BNF and a list of operator semantics) but I'm unable to find
Not just that. I'm looking for things which match either red or yellow or
green, but do NOT match ANY other color. I can probably drop the
requirement related to having no color.
On Sat, Sep 27, 2014 at 3:28 PM, Yonik Seeley yo...@heliosearch.com wrote:
On Sat, Sep 27, 2014 at 2:52 PM,
Sorry, color is multivalued, so a given record might be both blue and red.
I don't want those to show up in the results.
On Sat, Sep 27, 2014 at 3:36 PM, White, Bill bwh...@ptfs.com wrote:
Not just that. I'm looking for things which match either red or yellow or
green, but do NOT match ANY
On Sat, Sep 27, 2014 at 3:36 PM, White, Bill bwh...@ptfs.com wrote:
Sorry, color is multivalued, so a given record might be both blue and red.
I don't want those to show up in the results.
I think the only way currently (out of the box) is to enumerate the
other possible colors to exclude them.
Hmm, that won't work since color is free-form.
Is there a way to invoke (via fq) a user-defined function (hopefully
defined as part of the fq syntax, but alternatively, written in Java) and
have it applied to the resultset?
On Sat, Sep 27, 2014 at 3:41 PM, Yonik Seeley yo...@heliosearch.com
On Sat, Sep 27, 2014 at 11:36 PM, White, Bill bwh...@ptfs.com wrote:
but do NOT match ANY other color.
Bill, I miss the whole picture, it's worth to rephrase the problem in one
sentence.
But regarding the quote above, you can try to use exclusive ranges
OK, let me try phrasing it better.
How do I exclude from search, any result which contains any value for
multivalued field 'color' which is not within a given constraint set
(e.g., red, green, yellow, burnt sienna), given that I do not what
any of the other possible values of 'color' are?
In
On Sat, Sep 27, 2014 at 3:46 PM, White, Bill bwh...@ptfs.com wrote:
Hmm, that won't work since color is free-form.
Is there a way to invoke (via fq) a user-defined function (hopefully
defined as part of the fq syntax, but alternatively, written in Java) and
have it applied to the resultset?
Thanks!
On Sat, Sep 27, 2014 at 4:18 PM, Yonik Seeley yo...@heliosearch.com wrote:
On Sat, Sep 27, 2014 at 3:46 PM, White, Bill bwh...@ptfs.com wrote:
Hmm, that won't work since color is free-form.
Is there a way to invoke (via fq) a user-defined function (hopefully
defined as part of
indeed!
the exclusive range {green TO red} matches to the lemon yellow
hence, the negation suppresses it from appearing
fq=-color:{green TO red}
then you need to suppress eg black and white also
fq=-color:({* TO green} {green TO red} {red TO *})
I have no control over the
possible values of
Heh... very clever, Mikhail!
-Yonik
http://heliosearch.org - native code faceting, facet functions,
sub-facets, off-heap data
On Sat, Sep 27, 2014 at 4:43 PM, Mikhail Khludnev
mkhlud...@griddynamics.com wrote:
indeed!
the exclusive range {green TO red} matches to the lemon yellow
hence, the
Hmm. If I understand correctly this builds a set out of open intervals
(exclusive ranges), that's a great idea!
It doesn't seem to work for me, though; fq=-color:({* TO red} {red TO *})
is giving me results with color=burnt sienna
The field is defined as field name=color type=string
hm. try to convert it to query q=-color:({* TO red} {red TO *}) and check
the explanation from debugQuery=true
I tried to play with my index
q: *:*,
facet.field: swatchColors_string_mv,
fq: -swatchColors_string_mv:({* TO RED} {RED TO *}),
I got the following facets:
It worked for me once I changed to
-color:({* TO red} OR {red TO *})
I'm not sure why the OR is needed, maybe it's my version? (4.6.1)
On Sat, Sep 27, 2014 at 5:22 PM, Mikhail Khludnev
mkhlud...@griddynamics.com wrote:
hm. try to convert it to query q=-color:({* TO red} {red TO *}) and check
http://wiki.apache.org/solr/SchemaXml#Default_query_parser_operator ?
once again, debugQuery=true perfectly explains what's going on with q.
On Sun, Sep 28, 2014 at 1:24 AM, White, Bill bwh...@ptfs.com wrote:
It worked for me once I changed to
-color:({* TO red} OR {red TO *})
I'm not sure
Yes, that was it, thank you!
On Sat, Sep 27, 2014 at 5:28 PM, Mikhail Khludnev
mkhlud...@griddynamics.com wrote:
http://wiki.apache.org/solr/SchemaXml#Default_query_parser_operator ?
once again, debugQuery=true perfectly explains what's going on with q.
On Sun, Sep 28, 2014 at 1:24 AM,
17 matches
Mail list logo
