Multiple search queries with full text searches

Hello! I have a document of about 30k records which have the following key-value attributes:
“text1”: "SomethingText1"
“description”: “Description”
“manufacturer”: “Manufacturer”
“purposeId”: "183"
“color”: “Red”
“format”: “SomeFormat”
“name”: “SomeName”
“additional”: “true”
“outdoor”: “false”
My app needs to perform 2 queries. First query would be: “Get all the record that have a “purposeId” of 184 OR “additional” == true OR “outdoor” == false”. I can do this by creating a view which emits the purposeId, additional and outdoor keys. Second query would be a full text search similar to this: “text1 CONTAINS[c] %@ OR name CONTAINS[c] %@ OR manufacturer CONTAINS[c] %@ OR color CONTAINS[c] %@ OR description CONTAINS[c] %@”. I’ve managed to do it by creating a view that emits CBLTextKey and by using a “fullTextQuery”. The problem i’m having is that in some circumstance i need to combine these two queries, something similar to this: "Get all records that have a “purposeId” of 184 and “text1 CONTAINS[c] %@”. Building too many views is pretty costly because i have a lot data. Also filtering through the results of a view is pretty costly. I don’t know what’s the best way of doing or if there is even a way.


You can’t combine queries that way with map/reduce views; they’re lower-level than SQL. You’ll need to create a regular view and a full-text view, then query both and find the docIDs that appear in both result sets. That’s actually equivalent to what a SQL database would do under the hood.

Building too many views is pretty costly because i have a lot data.

Views are like indexes in a relational database. You’d need to set up multiple indexes to make SQL queries like the ones you listed efficient; the same goes for views.

In Couchbase Lite 2.0 (coming later this year; pre-beta dev builds available now) we’re switching to a query engine based on N1QL like Couchbase Server. You won’t be able to enter queries in N1QL syntax (we don’t have a parser for it) but you can use a native “fluent” API to create queries that have the same semantics. This should be a better fit for what you’re doing.

Thanks for the fast reply. Looking forward to the 2.0 version

FYI you can already try out the 2.0 query API in the latest developer build