How to add OR operator?

Are you using search pages or search views?
If you are using pages, please note that they will soon be removed from the core Search API project (in the next beta release) and you'll then have to download the module from the Search pages project. Also, you'd be in luck: #1261082: Conjunction option for search pages will add exactly that. You can try that patch out by applying it to the contrib/search_api_page folder. Please report back there whether it works.

Yes, that's correct. Just forgot to also add the conjunction as an option. It's a valid feature request, though, I'll fix that when I have time (which will take a bit, though).

Can you point me in the right direction for this? I'd be happy to make a patch

Subscribe - would love to see this enabled.

Ok, let's try this.

Attached patch adds a conjunction setting to the 'Fulltext search' filter configuration form (in handler_filter_fulltext.inc), and adds that conjunction to the query as an option using setOption().

Needs review and testing :)

I tried out this patch, and for some reason I'm getting 400 errors from Solr when I try and do a multiple keyword search with "Or" selected. Is there some special configuration I need to do in solrconfig.xml or something to get this patch to work? I've just got it set with the out-of-the-box configuration files from Search API right now. Pointers would be appreciated!

Joel

I also get the same error after applying this patch. But only when I try to use the OR operator, AND works normally.

An error occurred while trying to search with Solr: '400' Status: Bad Request.

This is a part of the working query I have in the Solr log. I have excluded some of the query because I have so many facets defined:

INFO: [] webapp=/solr path=/select params={facet=true...
title^5.0&qf=t_field_housing_company:field_address:thoroughfare^2.0&qf=t_field_housing_company:field_address:premise^2.0&qf=t_search_api_aggregation_1^1.0&json.nl=map&f.is_field_apartment_status.facet.limit=50&wt=json&rows=200&hl.snippets=3&facet.sort=count&start=0&f.is_field_housing_company:field_housing_company_type.facet.limit=50&q="word1"+"word2"} hits=0 status=0 QTime=49 

With OR operator I get first this error:
SEVERE: org.apache.solr.common.SolrException: no field name specified in query and no defaultSearchField defined in schema.xml

And the query in the Solr log looks like this:

INFO: [] webapp=/solr path=/select params={facet=true...
title^5.0:((("word1")+OR+("word2")))+OR+t_field_housing_company\:field_address\:thoroughfare^2.0:((("word1")+OR+("word2")))+OR+t_field_housing_company\:field_address\:premise^2.0:((("word1")+OR+("word2")))+OR+t_search_api_aggregation_1^1.0:((("word1")+OR+("word2")))} status=400 QTime=1 

Not sure what is the problem, but the query structure is very different from the working version above.

This problem has been fixed in the Search API Solr module's latest dev version, so it's now working with the patch in #6. See this issue for more details #1507818: OR queries throw 400 error.

Thanks for the testing! Indeed, the patch in #6 was made against the latest dev at the time (just like #1261082: Conjunction option for search pages).

Great work, thanks!
I'd be happy to commit this. However, one suggestion: could it maybe be better to include this in the operator, so the setting can easily be exposed?

Possible settings for the operator: "contains all of these words", "contains any of these words", "contains none of these words". In theory, there could also be "doesn't contain all of these words" (both OR and NOT), but I don't see that's relevant in practice.
We'd then look at the operator and thus determine what conjunction to use and whether to negate the query. (However, this would only be possible for "Use as: Search keys". I don't know what we should do if a user changes this setting (no matter how we implement it) with "Use as: Search filter". Probably we should at least note this somewhere in the admin UI.)

Yep, good idea to add the conjunction as an operator rather than a filter config option.

Attached patch adds an operator with the options mentioned in #11, passing the chosen operator setting to setOption() to add the conjunction to the query.

Some questions:

- I'm assuming it's ok to use strings like 'AND'/'OR'/'NOT' as array keys in operator_options()? I'm pretty new to views development, so not sure about this.
- Also views related: we should probably set the default value of the operators to 'AND'?
- Concerning the 'keys' vs 'filter' question: I added a description to the operator options form (which might need to be clarified). Other than that, it's probably good to only add the conjunction when the option is set to 'keys'.
- I can't get the 'NOT' query to work. I changed

if ($this->operator != '=') {

to

if ($this->operator == 'NOT') {

on line 48, not sure how that should be implemented though.

Setting this to 'needs work', looking forward to your comments :)

Here's a re-roll that also adds a conjunction setting for the fulltext argument handler. There's several dupes that could be marked for these two issues as well.

I have patch into my current system and I can see the operator at the Views->Configure filter criteria

• Contains all of these words
• Contains any of these words
• Contains none of these words

I select the Contains any of these words, saved, but it still behave like before.

This is my site http://victoria.my/products, I want the search_api can show either product from "mattress" OR "sofa" category...

ANy help would be greatly appreciate.

THanks.

Patch in #14 works fine for me. Attached is a reroll that fixes a whitespace error.

@maxchock: The search box on your site is a Drupal core search box, unless I'm missing something?

The patch looks very good on the whole, thanks a lot for all your work!
It just needs to take into account that NOT isn't a valid conjunction for Search API queries (only AND and OR are). Please see and test the attached patch for that.
I've also removed "NOT" for the argument (since I don't think it's expected there) and changed the option labels to those of the filter (since I think that would be clearer).

Thanks for the review!

The patch in #17 applies cleanly and works great. However, it still has the 'NOT' conjunction option for the filter, this patch removes that, so we only have the 'AND' and 'OR' options to choose from when configuring the fulltext filter (reading #17, I assume you meant to do that?).

Sorry, just read your comment and patch again and realized that was not what you meant :) (since we still want negation to work).

Attached patch is almost exactly the same as the one in #17, just fixes a comment typo.

OK, committed.
Thanks again for all your work!