I'm trying to query a text_general field named body for times like 9:15, 9:15pm, 9:15p, etc. I tried both of the following queries via the REST API without success:
q=body:9\:15* gives me no hits, missing docs that mention 9:15
q=body:"9:15"* gives me all docs, including docs that have nothing resembling 9:15
Debugging in Chrome, I enter these directly in the browser. I've also tried encodeURIComponent on the values to make sure the content isn't lost in HTTP translation. Same outcome either way.
I'm guessing there's a simple answer here and my mental model of how Solr queries work is just broken.
In cases like that I often do 2 things:
Turn Solr query debug on, so I can see that really goes into query. You will see extra node at the end of response.
&debug=query
Examine field analyser with Analysis tool. (url based on Solr's example core)
http://localhost:8983/solr/#/collection1/analysis?analysis.fieldvalue=9%3A30pm&analysis.query=9%3A30&analysis.fieldtype=text_general&verbose_output=0
Both methods should tell you exactly what is going wrong with your query. In second one you can check how matching work without reindexing anything.
Your time string gets tokenized following the Unicode standard annex UAX#29.
So the colon should be stripped out.
I think if you check you will see that your results should contain either 9 or 15.
Related
Say I have the following solr/lucene query:
https://some_website.com//api/myapi/search?profile=myprofile&fl=&fq=batchid:,bodytextsize_i*&q=word_i_want_to_search&partner=mypartnerid&rows=10
I would like to know what I can add to this in order to have the sentence or a certain range of words around the query word returned to me in the response. For instance say a document has the following sentence:
The computer's word_i_want_to_search is broken.
I would like to be able to query word_i_want_to_search and have the response show me the entire sentence. Is this possible?
Thank you!
This is known as highlighting:
Highlighting in Solr allows fragments of documents that match the
user’s query to be included with the query response.
The fragments are included in a special section of the query response
(the highlighting section), and the client uses the formatting clues
also included to determine how to present the snippets to users.
Fragments are a portion of a document field that contains matches from
the query and are sometimes also referred to as "snippets" or
"passages".
Use the parameters hl=true&hl.fl=field_you_are_searching and go from there. There's a lot of small things you can tweak to get different behaviors, such as how much data is being included in the response.
The following solr request works just fine:
&json.facet={domains:{type:terms,field:domains,domain:{excludeTags:DOMAIN}},specialties:{type:terms,field:specialties,domain:{excludeTags:SPECIALTY}}}
&fq={!tag=SPECIALTY}specialties:(1043 1023) AND {!tag=DOMAIN}domains:100
If I just change the order in the fq parameter, solr response with 400 Bad Request.
&json.facet={domains:{type:terms,field:domains,domain:{excludeTags:DOMAIN}},specialties:{type:terms,field:specialties,domain:{excludeTags:SPECIALTY}}}
&fq={!tag=DOMAIN}domains:100 AND {!tag=SPECIALTY}specialties:(1043 1023)
I would like to know if I'm doing something wrong or it if could be a problem in solr.
I'm using solr 7.2.1 and I'm following thes tutorial from Yonik:
http://yonik.com/multi-select-faceting/
A localparam (i.e. the thing between {}) has to be the first thing in a parameter. The second localparam you've added in the middle of your filterquery isn't being used as you expect it to, but when you move it to the front, it's suddenly being parsed.
You should split the two parts into separate fqs:
&fq={!tag=DOMAIN}domains:100
&fq={!tag=SPECIALTY}specialties:(1043 1023)
If you still get a Bad Request 400 - check the actual server log in your Solr instance - it'll show you what part it's barfing about (misspelling, etc.).
This is very weird. A colleague found that by adding an space between the tag and the field the query works as expected in any order. Also, adding the plus sign force to match all conditions. Here is the working query, just adding space and plus sign in fq parameter:
&json.facet={domains:{type:terms,field:domains,domain:{excludeTags:DOMAIN}},specialties:{type:terms,field:specialties,domain:{excludeTags:SPECIALTY}}}
&fq={!tag=DOMAIN} +domains:100 AND {!tag=SPECIALTY} +specialties:(1043 1023)
Use this with caution. This might be a hack. The documentation is not clear about this.
I'm performing 2 queries:
name:"\#"
name:"\#" AND userId:101
First query returns nothing and it's ok. But second query for some reason returns all records belonging to user.
What is wrong?
Your best bet when looking at a query and not knowing what is going on is by using the debugQuery option. It will show you what the string was entered in like as well as what it was parsed as.
There could be a lot of things going wrong. "#" could be one of your stop words. Also you could try sending a %23 since that is the url encoding for the # sign.
Whenever i query with q=: it shows all the documents but when i query with q=programmer 0 docs found.(contents is the default search field)
my schema has: id(unique),author,title,contents fields
Also query works fine for:
q=author:"Value" or q=title:"my book" etc, only for contents field no results.
Also when i query using spell checker(/spell?q=programmer) output shows spelling suggestions for this word,when 'programmer' is the right word and present in many documents.
I referred the example docs for configurations.
All of a sudden i am getting this,initially it worked fine.
I guess there some problem only in the contents field,but cannot figure it out.
Is it because indexes are not created properly for contents field?
(I am using solr 4.2 on Windows 7 with tomcat as webserver)
Please help.Thanks a lot in advance.
Are you sure you set the default search field? The reason you have this problem might be because you didn't set the <defaultSearchField> field in your schema.xml file. This is why "q=author:value" works while q=WHATEVER doesn't.
The Is used by Solr when parsing queries to
identify which field name should be searched in queries where an
explicit field name has not been used.
But also consider this:
The is used by Solr when parsing queries to
identify which field name should be searched in queries where an
explicit field name has not been used. It is preferable to not use or
rely on this setting; instead the request handler or query LocalParams
for a search should specify the default field(s) to search on. This
setting here can be omitted and it is being considered for
deprecation.
Do you have any data in your instance. try q=*:* and see what it returns. "for" is a stop word, may be it was filtered out. Look for something else as value to test.
I have a field in my solr schema as "Post Date"(exclude the quotes). when i fire a query with "fl" (field list) parameter in order to view only Post Date of search results, since this field contains a space I am not getting anything in the docs responses. I tried using +, %20 but still i get no results. Please help.
I would like to inform that i have found a solution to this. I tried experimenting and hence came up with a solution on putting \+ as the substitute for white space in the query. Hence the query should be Post\+Date:[ranges]
I couldnt aford to change my schema as many teams are depending on it and we are upgrading our system to a new search engine.
You can specify (what Solr deems crazy) fields by wrapping them like this:
field(Post Date)
This actually changes the returned results fieldname too so you'll get back something like:
"field(Post Date)" : "2010-01-01"
And not just the name as you might imagine.
As a possible workaround, you might be able to use a wild card to achieve your results. Using the solr wiki http://wiki.apache.org/solr/CommonQueryParameters#glob you may be able to specify fl=Post*Date which would possibly get around your problem. I have not verified this but it might work.
Update: This doesn't seem to work on either version of solr I tried (1.4.0 and 3.6.1). Looks like this may have been discussed at http://wiki.apache.org/solr/FieldAliasesAndGlobsInParams but it does not appear to be implemented.