0

I have indexed a file with fields -

  1. Content (type :text_general, uninvertible :false, indexed :true, stored :true)
  2. Category (type :text_general, uninvertible :false, indexed :true, stored :true)
  3. Title (type :text_general, uninvertible :false, indexed :true, stored :true)

with a catch-all copyfield-

source: *,
dest :_text_

Now when I search Content field, for query - Apple trade , I get 6057 docs;

But when I search - trade Apple , I get 5878 docs.

However when the same search is performed on the catch-all field , I get same result for both the queries (6057 docs).

I am not understanding the mistake here, as I would wish solr to give same result for both queries when searched on Content field.

I am using-

  • LuceneQParser
  • ClassicSimilarity

Two queries on 'Content' Field :

  1. Apple trade

http://localhost:8983/solr/core_name/select?q=Content%3A%20Apple%20trade

  1. trade Apple

http://localhost:8983/solr/core_name/select?q=Content%3A%20trade%20Apple

atinjanki
  • 483
  • 3
  • 13
  • What is _your actual search query_, with the complete query string? My guess is that you're assuming that `trade Apple` is searched in the `Content` field, when just `trade` is - and `Apple` is searched in the default search field. – MatsLindh Jan 06 '20 at 20:59
  • Query string is -'Apple trade' , but when I type - 'trade Apple' the result changes. I wish to achieve same results in both the cases – atinjanki Jan 06 '20 at 23:05
  • Include your complete query - which query parser are you using? Are you using single quotes? Are you looking for a phrase match? (in which case, when using quotes, the sequence of terms matter) – MatsLindh Jan 07 '20 at 07:41
  • I have updated details in the post. No, I am not using quotes. I am using -LuceneQParser. No, I am not doing a phrase match. I have two queries as listed above which I am searching on 'Content' field (details of which are written in the post) and I am trying to achieve same results for the two queries. – atinjanki Jan 07 '20 at 14:26
  • Add _the complete query string_ you're sending to Solr. From your examples given in the comments (`-` prefix) they're different from what you've added in your question. Also append `debug=all` to your query and include the relevant part about how the query is parsed. – MatsLindh Jan 07 '20 at 14:35

1 Answers1

1

From what you just added to your question and assuming the Lucene query parser ignores the space after your :, the query is Content:trade <default search field>:Apple - you're not searching for both the first and second term in the Content field.

When you swap their places, you're searching for Content:Apple <default search field>:trade.

The default search field is _text_ in the default configuration. Since the queries are different, you can assume that there is different content in the field (for example by not reindexing properly and cleaning out the index after adding the copyField instruction).

If you want to use free text search that easily maps to user input, use the edismax query parser instead (defType=edismax), supply the query in q=apple trade, and supply the field names in qf=Content.

MatsLindh
  • 49,529
  • 4
  • 53
  • 84
  • Yes , that is the issue which is happening, the first and second terms were not being searched together in Content. And when the same two queries are searched on default search field (without 'Content:' ), they give same results. So from your answer is it correct to interpret that this issue cannot be resolved with Lucene Parser and hence Edismax should be used? – atinjanki Jan 07 '20 at 14:57
  • Sure, you can resolve it - either by giving `Content` as the default field - by setting it explicitly - `df=Content` - or by prefixing each term with the field: `Content:Apple Content:trade`. But for using "natural" query strings, the edismax handler usually behaves better and allows you to search in multiple fields with weights given between the fields. `qf=Content Title^10` would give a tenfold boost to hits in the `Title` field which usually should be considered more important. – MatsLindh Jan 07 '20 at 16:21
  • Thanks Man!It helped in understanding the issue better:) – atinjanki Jan 09 '20 at 22:17