I'm trying to calculate the tf*idf of a term in my index.
Following Yonik's post from http://yonik.com/posts/solr-relevancy-function-queries/ I tried
http://localhost:8080/solr/select/?fl=score,id&defType=func&q=mul(tf(texto_completo,bug),idf(texto,bug))
(where texto_completo is the field, and 'bug' is the term) without much success. The response was:
error 400: The request sent by the client was syntactically incorrect (null).
I went ahead and looked at this answer /a/13477887 so I tried to do a simpler function query:
http://localhost:8080/solr/select/?q={!func}docFreq(texto_completo,bug)
And yet, I got the same error.
What is my syntax lacking to work properly?
For this not working:
q={!func}docFreq(texto_completo,bug)
use all lower-case docfreq:
q={!func}docfreq(texto_completo,bug)
I just tried:
q={!func}mul(tf(name,movie),idf(name,movie))
in Solr 4.2.1 and it is working fine. My field name is name (Text type) and term I am looking for is movie.
UPDATE: You need at least Solr 4.0 to use these. See http://wiki.apache.org/solr/FunctionQuery#Relevance_Functions
Related
kibana 4 gives an error "Discover: An error occurred with your request. Reset your inputs and try again" 80% of the time when I try to sort by a numeric field. It works fine when sorted by any other field. Did anyone get this issue?
I had this when I had added a sequence number in logstash to index (because several logs could be added in the same millisecond, causing the sort not to show the ordering correctly).
If you open up firefox debugger and view the console, it will show you more information related to the error. In my case
java.lang.Long cannot be cast to org.apache.lucene.util.BytesRef
I added
{ "unmapped_type": "number" }
into the advance settings - sort:options. It returns sorted data correctly but appears to throw a yellow warning.
Yes. I had that issue and opening the browser's javascript console helped me to see that a non-JSON document was the problem. Apparently, you can store non-JSON in elasticsearch (at least I can with 1.6.2). That creates problems with Kibana.
So: Open the browser's console, look for "error parsing body" or smth similar. You should also get the faulty string. Use that to identify to culprit document.
We have the same requirement of passing huge data like http://bugsquash.blogspot.in/2010/12/customizing-solrnet.html, we tried the following.
1) Increased the requestHeaderSize to Int32.MaxValue - stackoverflow exception
2) Used PostSolrconnection - got the StackOverflow exception.
3) Downloaded the source of solrnet and added as project reference - Stackoverflow exception
Then even we changed to GET, we are getting the StackOverflow exception. The error is coming when we have more than 500 reference ids. If we have less values, it works.
This is how we are calling,
searchResults = solrPost.Query(new SolrMultipleCriteriaQuery(new[]
{
query
}),
new SolrNet.Commands.Parameters.QueryOptions
{
Fields = new[] { "*", "score" },
Start = pageSize,
Rows = 40,
OrderBy = listSort
});
Any ideas?
EDIT:
We tried requesting solr using HttpRequest and identified as maxBooleanClause issue and then POST started working through HttpRequest. But using SolrNet the error is occurred and it is happening at serializing the query object. queryserializer.serialize(Query)
Wondering why step 2 didn't work which is the exact fix for the long Get request issue, i.e. to switch over to Post request.
Chances are there is an issue with the piece of code where you are initialising SolrNet to use PostSolrConnection instead of the default SolrConnection. Need to look at the bit of code which gets you the instance of solrPost object. Take another look at it and post it here.
Unfortunately the SolrNet didn't work due to stackoverflow error while serializing the query parameters. Alternate workaround is posted http://smartcoder.in/solrnetstackoverflow/
Going from Joomla 2.5 to 3.0 with my extension, I'm struggling with how to do the DB error handling (since GetErrorNum is deprecated, see also Joomla! JDatabase::getErrorNum() is deprecated, use exception handling instead).
The way that seems to be the one to go according to the question linked above, is to add the following code for each db->query() code:
if (!$db->query()) {
throw new Exception($db->getErrorMsg());
}
In my opinion, that makes DB error handling more awkward than it was before. So far, I simply called a checkDBError() function after a DB call, which queried the ErrorNum and handled any possible error accordingly.
That was independent from how the DB query was actually triggered - there are different ways to do that, and different results on an error: $db->loadResult() returns null on error, $db->query() returns false. So there will now be different checks for different DB access types.
Isn't there any generic way to handle this, e.g. a way to tell Joomla to throw some exception on DB problems? Or do I have to write my own wrapper around the DatabaseDriver to achieve that? Or am I maybe missing something obvious?
Or should I just ignore the deprecation warning for now and continue with using getErrorNum()? I'd like to make my extension future-proof, but I also don't want to clutter it too much with awkward error handling logic.
Just found this discussion: https://groups.google.com/forum/#!msg/joomla-dev-general/O-Hp0L6UGcM/XuWLqu2vhzcJ
As I interpret it, there is that deprecation warning, but there is no proper replacement yet anyway...
Unless somebody points out any other proper documentation of how to do it in 3.0, I will keep to the getErrorNum method of doing stuff...
Get getErrorNum() function will solve your problem....
$result = $db->loadResult();
// Check for a database error.
if ($db->getErrorNum())
{
JFactory::getApplication()->enqueueMessage($db->getErrorMsg());
return false;
}
I'm using splunk-client to extract results from splunk. Here's the code:
query = "sourcetype=collection #{order_id}"
search = #splunk_client.search(query)
search.wait
The search is happening fine, and it seems like I'm doing everything according to the example (https://github.com/cbrito/splunk-client), but I get this error on the 'search.wait' line:
Undefined namespace prefix: //s:key[#name='isDone']
Any ideas what could be going wrong? Running these commands in irb works fine. Is there some sort of blocking issue?
There is currently very little error checking which occurs within the gem itself. The reason for the error is that wait looks for the status of the isDone key to change to true.
Since your credentials were not properly setup in the first place, the gem creates a search object with an invalid session. The search does not initially fail, because enough response came back from Splunk that Nokogiri processes it into an object without a Splunk search sid.
In the future I should likely raise an exception if a proper sid is not returned to avoid confusion.
Source: I wrote the gem.
I found out the issue -- the splunk client wasn't authenticating properly, and so search was actually a broken SplunkJob object (with a nil username and authentication key). It's strange that there was no error raised until the wait command, but upon inspecting the search object, one of the fields stated that the object was malformed.
I'm using tire and elasticsearch. The service has started using port 9200. However, it was returning 2 errors:
"org.elasticsearch.search.SearchParseException: [countries][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{"query":{"query_string":{"query":"name:"}}}]]"
and
"Caused by: org.apache.lucene.queryParser.ParseException: Cannot parse 'name:': Encountered "<EOF>" at line 1, column 5."
So, I reinstalled elasticsearch and the service container. Service starts fine.
Now, when I search using tire I get no results when results should appear and I don't receive any error messages.
Does anybody have any idea how I might find out what is wrong, let alone fix it?
first of all, you don't need to reindex anything, in the usual cases. It depends how you installed and configured elasticsearch, but when you install and upgrade eg. with Homebrew, the data are persisted safely.
Second, no need to reinstall anything. The error you're seeing means just what it says on the tin: SearchParseException, ie. your query is invalid:
{"query":{"query_string":{"query":"name:"}}}
Notice that you didn't pass any query string for the name qualifier. You have to pass something, eg:
{"query":{"query_string":{"query":"name:foo"}}}
or, in Ruby terms:
Tire.index('test') { query { string "name:hey" } }
See this update to the Railscasts episode on Tire for an example how to catch errors due to incorrect Lucene queries.