I had originally created in my solr schema 3 copy fields:
curl -X POST -H 'Content-type:application/json' --data-binary '{"add-copy-field": {"source":"company_name","dest":"_text_"}}' http://my-instance/solr/listing/schema
curl -X POST -H 'Content-type:application/json' --data-binary '{"add-copy-field": {"source":"address","dest":"_text_"}}' http://my-instance/solr/listing/schema
curl -X POST -H 'Content-type:application/json' --data-binary '{"add-copy-field": {"source":"city","dest":"_text_"}}' http://my-instance/solr/listing/schema
However, I have recently removed these from the schema and are now composing queries in a slightly different format. More advanced queries we have the need for edismax.
However, even by turning on edismax I'm receiving an error from the solr query parser as per below. Did I break something by deleting the copy fields?
/solr/listing/select?debugQuery=on&defType=edismax&q=%3A&stopwords=true
{
"responseHeader": {
"zkConnected": true,
"status": 400,
"QTime": 1,
"params": {
"q": "*:*",
"defType": "edismax",
"debugQuery": "on",
"stopwords": "true"
}
},
"error": {
"metadata": [
"error-class",
"org.apache.solr.common.SolrException",
"root-error-class",
"org.apache.solr.common.SolrException"
],
"msg": "org.apache.solr.search.SyntaxError: Query Field '_text_' is not a valid field name",
"code": 400
}
}
As per the comments the 'text' field remains in 3 places in the config:
"/update/extract":{
"startup":"lazy",
"name":"/update/extract",
"class":"solr.extraction.ExtractingRequestHandler",
"defaults":{
"lowernames":"true",
"fmap.content":"_text_"}}
"spellchecker":{
"name":"default",
"field":"_text_",
"initParams":[{
"path":"/update/**,/query,/select,/tvrh,/elevate,/spell,/browse",
"defaults":{"df":"_text_"}}]
As per the comment on my question (I'm still on the learning path of solr):
Although they have been deprecated for quite some time, Solr still has
support for Schema based configuration of a <defaultSearchField/>
(which is superseded by the df parameter) and <solrQueryParser defaultOperator="OR"/> (which is superseded by the q.op parameter.
If you have these options specified in your Schema, you are strongly
encouraged to replace them with request parameters (or request
parameter defaults) as support for them may be removed from future
Solr release.
For our purposes and as we are using the edismax query parser we needed to specify the query fields that we wanted to use.
2+ year old post, not sure this will help.
Since you are using "defType": "edismax"
try "q.alt": "*:*" instead of "q": "*:*". This should fix the issue.
Related
In the Solr documentation it focuses explanations on how to use the GET parameters to define queries, but gives very little information on how to accomplish the same tasks using the better structured JSON POST support. I have been unable to find any documentation that goes deeper than very surface-level explanation.
Particularly, I'm trying to utilize local params in my queries and would like to know how to accomplish the following using a JSON POST instead of GET params:
http://localhost:8983/solr/city/query?sort={!sfield=location pt=35.5514,-97.4075}geodist() asc&q={!geofilt sfield=location pt=35.5514,-97.4075 d=5}
According to JSON Request API / Parameters Mapping your query would map to:
{
"sort": "{!sfield=location pt=35.5514,-97.4075}geodist() asc",
"query": "{!geofilt sfield=location pt=35.5514,-97.4075 d=5}"
}
Just to complete #MatsLindh answer, you can use usual parameter names as long as you wrap them in params (no mapping needed), for example :
file.json
{
"params": {
"q":"{!geofilt sfield=location pt=35.5514,-97.4075 d=5}",
"sort":"{!sfield=location pt=35.5514,-97.4075}geodist() asc",
"wt": "json",
"indent": "true"
}
}
Request example using curl :
curl -H "Content-Type: application/json" -X "POST" --data #file.json http://localhost:8983/solr/city/query
I have setup apache solr 7.1 and using postman tool to query it. But when I am trying to delete indexed data using postman I get following error.
Request:
GET http://localhost:8983/solr/solr-sample3/update?stream.body={
"delete": {
"query": "*:*"
},
"commit": { }
}
Body:
{
"error": {
"metadata": [
"error-class",
"org.apache.solr.common.SolrException",
"root-error-class",
"org.apache.solr.common.SolrException"
],
"msg": "Stream Body is disabled. See http://lucene.apache.org/solr/guide/requestdispatcher-in-solrconfig.html for help",
"code": 400
}
}
It was working in previous solr version solr 6.6. I went through the lucene documentation but I am not able to figure it out.
You don't need to enable the stream body. Just use a curl POST request specifying the data type as text/xml
curl http://localhost:8983/solr/solr-sample3/update?commit=true -H "Content-Type: text/xml" --data-binary '<delete><query>*:*</query></delete>'
Or if you're using the Post Tool included in solr:
bin/post -c core_name -type text/xml -out yes -d $'<delete><query>*:*</query></delete>'
I went though the documentation, it says i need to enable stream body as it has been disabled in solr 7.1 .
to enable use :
curl http://localhost:8983/solr/solr-sample3/config -H 'Content-type:application/json' -d'{
"set-property" : {"requestDispatcher.requestParsers.enableRemoteStreaming":true},
"set-property" : {"requestDispatcher.requestParsers.enableStreamBody":true}
}'
Here is what worked for me, using cURL and avoiding to enable stream body:
curl http://localhost:8983/solr/solr-sample3/update?commit=true -X POST -H "Content-Type: text/xml" --data-binary "<delete><query>*:*</query></delete>"
So I have a three-node cluster deployed using a zookeeper. And successfully created test collection (3 shards). Then after I have
curl -X POST -H 'Content-Type: application/json' 'ec2FirstNodeIP:8983/solr/test/update' --data-binary ' [ { "f1" : "1", "f2" : "2", "f3" : "3" } ]'
I got
{"responseHeader":{"status":0,"QTime":38} ...
However when I have curl "sameIP:8983/solr/test/select?wt=json&indent=true&q=*:*"
I am getting
NumFound:0
But using the admin UI for updating the document, the query now returns the document
image for admin UI
What am I missing?
To make document searchable we should commit. use commit=true
ec2FirstNodeIP:8983/solr/test/update?commit=true this should work.
I'm doing the most basic of solr queries with faceting.
q=*:*&facet=true&facet.field=year
And I'm getting an error as follows:
{
"responseHeader": {
"status": 400,
"QTime": 1,
"params": {
"indent": "true",
"q": "*:*&facet=true&facet.field=year",
"_": "1443134591151",
"wt": "json"
}
},
"error": {
"msg": "undefined field *",
"code": 400
}
}
This query is straight out of the online tutorials. Why is solr complaining?
It appears that what you have done is gone to the Solr Admin panel and in the query section you have put
*:*&facet=true&facet.field=year
after the q. What you need to do is put *:* after the q, and facet=true&facet.field=year under Raw Query Parameters.
The error says, that you have "undefined field". Is "year" field defined in your schema? Also, can you give details about how you are querying the data. Like which client?And I assume that q=: is working and issue is only with faceting
You've put it into the wrong line in the solr admin.
Just take the same line, and paste it into the Raw query line instead of the query line.
I am sending the following json:
{
"components": [
{
"guid": "com.mycompany.MyPlugin",
"duration": 60,
"metrics": {
"Component/Memory/Heap Used[bytes]": 146990608,
"Component/Processor/GC[percent]": 0.5555555555555556,
"Component/Memory/Heap Max[bytes]": 39387136,
"Component/Processor/CPU[percent]": 66.66666666666667,
"Component/Memory/Heap Committed[bytes]": 279714288
},
"name": "MyPlugin"
}
],
"agent": {
"host": "host",
"pid": 0,
"version": "1.0.0"
}
}
The Component/Memory/* metrics are properly recognized by new relic and i am able to create dashboards.
But, the Component/Processor/* metrics dont seem to acknowledged at all. I cant see them in the dropdown list of metric names when i create a new dashboard and even typing the name manually doesn't work since new relic says no such metric exists.
It is recommended that GUID values be all lower case. At present GUIDs with differing case are treated as unique.
EDIT:
Try curling with your data as a test:
curl -vi https://platform-api.newrelic.com/platform/v1/metrics
-H "X-License-Key: <LICENSE_KEY>"
-H "Content-Type: application/json"
-H "Accept: application/json"
-X POST -d '<JSON_DATA>'