I'm using solr 4.2. And I've implemented Advanced search in my application. In this search, one option is there for 'include all these words'. so whenever i put any word or any phrase without stop words, it works fine but with stop words, it returns no result.
For example:
Query: purchase tune
This query works fine but if i put query like:'i would like to purchase tune'
then it gives no results.
Why is so? And what i need to do?
Also for this kind of search I was using 'mm' parameter in solr. But now using 'q.op'.
In solr i'm adding param q.op as following
params.add("q.op","AND");
and query as
params.add("q",query);
Do you encounter the problem with the Dismax Handler and the mm parameter?
The DisMax handler has an issue with stopwords:
https://issues.apache.org/jira/browse/SOLR-3085
In this ticket you find some workarounds:
Typical solution is to not use stopwords or harmonize stopword lists
across all fields in your QF, or relax the MM to a lower percentag.
Sometimes these are not acceptable workarounds, and we should find a
better solution.
Perhaps "harmonize stopword lists" is a suitable soluation for your problem.
Related
i just built a search form backed by solr, we are using the solarium library to construct our requests.
we built a "huge" collection of filterqueries like that one:
$query = $client->createQuery($client::QUERY_SELECT);
$query->setStart(0)->setRows(1000);
$query->addFilterQuery($query->createFilterQuery("foo")->setQuery("bar:true"));
$query->addFilterQuery($query->createFilterQuery("fo")->setQuery("ba:false"));
....
but we realized that the search just hits all the single fields we specify in the filterqueries, but we have to actually query multiple fields. while reading the docs i realized we could have been wrong, right? the correct approach would be to use disMax queries (in combination with facets?)? im wondering, can we use DisMax in combination with filterqueries to "expand" our search to multiple fields (with boosts) ? or do we have to actually rework everything?
im kinda missing the big picture to decide what the best/working solution would be
help is much appreciated
edit:
solr:
solr-spec 7.6.0
solarium:
solarium/solarium 6.0.1 PHP Solr client
You can give a query parser when giving the fq argument:
fq={!dismax qf="firstfield secondfield^5"}this is my query
The syntax is known as Local Parameters. Since dismax (or edismax which you should normally use now) doesn't have a identifier in front of it, it is implicitly parsed as the type.
If a local parameter value appears without a name, it is given the implicit name of "type". This allows short-form representation for the type of query parser to use when parsing a query string.
You'll have to make sure that Solarium doesn't escape the value you give to setQuery, but seeing as you're already giving a field:value combination, it doesn't seem to get escaped. Double check the Solr log to see exactly what query is being sent to Solr (or ask Solarium to give you the exact query string being sent if possible).
I'm having a problem with the Solr 3.6.2 default (field based) spellchecker configured with query time parameters
spellcheck.onlyMorePopular=true
spellcheck.count=5
spellcheck.collate=true
spellcheck.maxCollations=5
spellcheck.maxCollationTries=5
on a field type which has a solr.StopFilterFactory filter on its analyzers.
The suggestion phase works as intended :
the indexed field does not contain any stopword
no suggestion is provided for a given stopword
But the resulting collation always contains the ignored stopwords, which I don't want: I'd prefer a raw suggestion of combined terms over something which looks like a "sort of" natural language answer.
For instance, searching for "handfum of perries", I'd prefer "handful berry" over "handful of berry".
I don't think that the stopwords excluded from spellchecking suggestions because of the field query analyzer are "marked" for preservation like the official documentation goes about other query elements :
Note that the non-spellcheckable terms such as those for range
queries, prefix queries etc. are detected and excluded for
spellchecking. Such non-spellcheckable terms are preserved in the
collated output so that the original query can be run again, as is.
It seems two solutions would be
either having a custom query converter so the stopwords are ignored right from the start: not sure it is possible in 3.6.2
or having a custom spellchecker that would not try to find any suggestion for a stopword (or would always suggest an "empty" string), without messing up the collation process
Am I missing something ?
Regards
Specifically if I'm doing a query using the solr mlt handler (http://wiki.apache.org/solr/MoreLikeThisHandler) and stream.body to supply the source doc is there any way to boost result documents based on document age?
I already know how to do that for a regular query using dismax (http://wiki.apache.org/solr/FunctionQuery#Date_Boosting) but I can't quite figure out the magic incantation to do it for the mlt handler.
It looks like the mlt handler is written to handle one of two cases:
q=[typical query goodness which can include date boosting]
stream.body=[url]
If q is present, stream.body is ignored and vice-versa, so unfortunately I don't think you'll be able to do what you want in a single call without patching the MoreLikeThisHandler.
BUT: If you need this in a hurry, you can do it with two queries
Run your same MLT query solely for the purpose of retrieving the interesting-terms and boosts (e.g with mlt.interestingTerms=details&mlt.boost=true&rows=0)
Using the interesting-terms and boosts from (1), run a standard Solr query (non-MLT) with the date-boosting function you desire.
I'm working with Solr and I'd like to know if it is possible to have a LIKE clause in the query. For example, I want to know all organizations with "New York" in the title. In SQL, this would be written like Name LIKE 'New York%'.
My question - how do you write a LIKE query in Solr?
I'm using the SolrNet library, if that makes a difference.
You just search for "New York", but first you need to properly configure your field's analyzer. For example you might want to start with a field type like text_general as defined in the default Solr schema. This field type will tokenize on whitespace and other common word separators, then apply a filter of stopwords, then lowercase the terms in order to make searches case-insensitive.
More information about analyzers in the Solr wiki.
If you're using solr 3.1 or newer, have a look at the Extended DisMax Query Parser, which supports wildcard queries. You can enable it using <str name="defType">edismax</str> in the request handler configuration.
Then you can use a query like title:New York* with the same behaviour as a query with like clause. The main difference between my answer and the accepted one is that you can even search for fragment of words using wildcards. For example New Yorkers would match in this case.
Unfortunately you could have problems with case-sensitive queries even if you're using a LowerCaseFilterFactory. Have a look here to know more. Most of those problems will be fixed with the solr 3.6 release since the SOLR-2438 issue has been solved.
Solr newbie here.
I have created a Solr index and write a whole bunch of docs into it. I can see
from the Solr admin page that the docs exist and the schema is fine as well.
But when I perform a search using a test keyword I do not get any results back.
On entering * : *
into the query (in Solr admin page) I get all the results.
However, when I enter any other query (e.g. a term or phrase) I get no results.
I have verified that the field being queried is Indexed and contains the values I am searching for.
So I am confused what I am doing wrong.
Probably you don't have a <defaultSearchField> correctly set up. See this question.
Another possibility: your field is of type string instead of text. String fields, in contrast to text fields, are not analyzed, but stored and indexed verbatim.
I had the same issue with a new setup of Solr 8. The accepted answer is not valid anymore, because the <defaultSearchField> configuration will be deprecated.
As I found no answer to why Solr does not return results from any fields despite being indexed, I consulted the query documentation. What I found is the DisMax query parser:
The DisMax query parser is designed to process simple phrases (without complex syntax) entered by users and to search for individual terms across several fields using different weighting (boosts) based on the significance of each field. Additional options enable users to influence the score based on rules specific to each use case (independent of user input).
In contrast, the default Lucene parser only speaks about searching one field. So I gave DisMax a try and it worked very well!
Query example:
http://localhost:8983/solr/techproducts/select?defType=dismax&q=video
You can also specify which fields to search exactly to prevent unwanted side effects. Multiple fields are separated by spaces which translate to + in URLs:
http://localhost:8983/solr/techproducts/select?defType=dismax&q=video&qf=features+text
Last but not least, give the fields a weight:
http://localhost:8983/solr/techproducts/select?defType=dismax&q=video&qf=features^20.0+text^0.3
If you are using pysolr like I do, you can add those parameters to your search request like this:
results = solr.search('search term', **{
'defType': 'dismax',
'qf': 'features text'
})
In my case the problem was the format of the query. It seems that my setup, by default, was looking and an exact match to the entire value of the field. So, in order to get results if I was searching for the sit I had to query *sit*, i.e. use wildcards to get the expected result.
With solr 4, I had to solve this as per Mauricio's answer by defining type="text_en" to the field.
With solr 6, use text_general.