how do I create a “like” filter view in couchdb

Question

Here\'s an example of what I need in sql:

SELECT name FROM employ WHERE name LIKE %bro%

How do I create view li

Answer 1

Unfortunately, doing searches using LIKE %...% aren't really how CouchDB Views work, but you can accomplish a great deal of search capability by installing couchdb-lucene, it's a fulltext search engine that creates indexes on your database that you can do more sophisticated searches with.

The typical way to "search" a database for a given key, without any 3rd party tools, is to create a view that emits the value you are looking for as the key. In your example:

function (doc) {
    emit(doc.name, doc);
}

This outputs a list of all the names in your database.

Now, you would "search" based on the first letters of your key. For example, if you are searching for names that start with "bro".

/db/_design/test/_view/names?startkey="bro"&endkey="brp"

Notice I took the last letter of the search parameter, and "incremented" the last letter in it. Again, if you want to perform searches, rather than aggregating statistics, you should use a fulltext search engine like lucene. (see above)

Answer 2

The simple answer is that CouchDB views aren't ideal for this.

The more complicated answer is that this type of query tends to be very inefficient in typical SQL engines too, and so if you grant that there will be tradeoffs with any solution then CouchDB actually has the benefit of letting you choose your tradeoff.

1. The SQL Ways

When you do SELECT ... WHERE name LIKE %bro%, all the SQL engines I'm familiar with must do what's called a "full table scan". This means the server reads every row in the relevant table, and brute force scans the field to see if it matches.

You can do this in CouchDB 2.x with a Mango query using the $regex operator. The query would look something like this for the basic case:

{"selector":{
  "name": {
    "$regex": "bro"
  }
}}

There do not appear to be any options exposed for case-sensitivity, etc. but you could extend it to match only at the beginning/end or more complicated patterns. If you can also restrict your query via some other (indexable) field operator, that would likely help performance. As the documentation warns:

Regular expressions do not work with indexes, so they should not be used to filter large data sets. […]

You can do a full scan in CouchDB 1.x too, using a temporary view:

POST /some_database/_temp_view

{"map": "function (doc) { if (doc.name && doc.name.indexOf('bro') !== -1) emit(null); }"}

This will look through every single document in the database and give you a list of matching documents. You can tweak the map function to also match on a document type, or to emit with a certain key for ordering — emit(doc.timestamp) — or some data value useful to your purpose — emit(null, doc.name).

2. The "tons of disk space available" way

Depending on your source data size you could create an index that emits every possible "interior string" as its permanent (on-disk) view key. That is to say for a name like "Dobros" you would emit("dobros"); emit("obros"); emit("bros"); emit("ros"); emit("os"); emit("s");. Then for a term like '%bro%' you could query your view with startkey="bro"&endkey="bro\uFFFF" to get all occurrences of the lookup term. Your index will be approximately the size of your text content squared, but if you need to do an arbitrary "find in string" faster than the full DB scan above and have the space this might work. You'd be better served by a data structure designed for substring searching though.

Which brings us too...

3. The Full Text Search way

You could use a CouchDB plugin (couchdb-lucene now via Dreyfus/Clouseau for 2.x, ElasticSearch, SQLite's FTS) to generate an auxiliary text-oriented index into your documents.

Note that most full text search indexes don't naturally support arbitrary wildcard prefixes either, likely for similar reasons of space efficiency as we saw above. Usually full text search doesn't imply "brute force binary search", but "word search". YMMV though, take a look around at the options available in your full text engine.

If you don't really need to find "bro" anywhere in a field, you can implement basic "find a word starting with X" search with regular CouchDB views by just splitting on various locale-specific word separators and omitting these "words" as your view keys. This will be more efficient than above, scaling proportionally to the amount of data indexed.

Answer 3

I know it is an old question, but: What about using a "list" function? You can have all your normal views, andthen add a "list" function to the design document to process the view's results:

{
  "_id": "_design/...",
  "views": {
    "employees": "..."
  },
  "lists": {
    "by_name": "..."
  }
}

And the function attached to "by_name" function, should be something like:

function (head, req) {
  provides('json', function() {
    var filtered = [];

    while (row = getRow()) {
      // We can retrive all row information from the view
      var key = row.key;
      var value = row.value;
      var doc = req.query.include_docs ? row.doc : {};

      if (value.name.indexOf(req.query.name) == 0) {
        if (req.query.include_docs) {
          filtered.push({ key: key, value: value, doc: doc});
        } else {
          filtered.push({ key: key, value: value});
        }
      }
    }

    return toJSON({ total_rows: filtered.length, rows: filtered });
  });
}

You can, of course, use regular expressions too. It's not a perfect solution, but it works to me.

Answer 4

You could emit your documents like normal. emit(doc.name, null); I would throw a toLowerCase() on that name to remove case sensitivity.

and then query the view with a slew of keys to see if something "like" the query shows up.

keys = differentVersions("bro"); // returns ["bro", "br", "bo", "ro", "cro", "dro", ..., "zro"]
$.couch("db").view("employeesByName", { keys: keys, success: dealWithIt } )

Some considerations

1. Obviously that array can get really big really fast depending on what differentVersions returns. You might hit a post data limit at some point or conceivably get slow lookups.

2. The results are only as good as differentVersions is at giving you guesses for what the person meant to spell. Obviously this function can be as simple or complex as you like. In this example I tried two strategies, a) removed a letter and pushed that, and b) replaced the letter at position n with all other letters. So if someone had been looking for "bro" but typed in "gro" or "bri" or even "bgro", differentVersions would have permuted that to "bro" at some point.

3. While not ideal, it's still pretty fast since a look up in Couch's b-trees is fast.

Answer 5

You can use regular expressions. As per this table you can write something like this to return any id that contains "SMS".

{
   "selector": {
      "_id": {
         "$regex": "sms"
      }
   }
}

Basic regex you can use on that includes

"^sms" roughly to LIKE "%sms"
"sms$" roughly to LIKE "sms%"

You can read more on regular expressions here

Answer 6

i found a simple view code for my problem...

{
"getavailableproduct":
       { "map": "function(doc) {
           var prefix = doc['productid'].match(/[A-Za-z0-9]+/g);
           if(prefix)
              for(var pre in prefix) { emit(prefix[pre],null); }
            }"
       }
}

from this view code if i split a key sentence into a key word... and i can call

?key="[search_keyword]"

but i need more complex code because if i run this code i can only find word wich i type (ex: eat, food, etc)...

but if i want to type not a complete word (ex: ea from eat, or foo from food) that code does not work..