0

It may be related to this question Basic GROUP BY statement using OPA MongoDB high level API.

I want to be able to retrieve a list of documents which "name" field value contains a given string.

Here's my documents list :

{name: "Charles-Hugo"}, {name: "Jean Pierre"}, {name: "Pierre Dupont"},

I want to be able to only retrieve documents which name contains the "Pierre" string: Jean Pierre, and Pierre Dupont.

I know this isn't possible with the MongoDB high-level API. I've looked in the low-level API functions but I don't know what's the easiest way to retrieve my documents in safe Opa type.

Also I'd like to add skip/limit options to my query.

Any idea ?

Community
  • 1
  • 1
gogson
  • 930
  • 2
  • 8
  • 11
  • I dont know anything about Opa but this may help you http://stackoverflow.com/questions/3305561/how-to-query-mongodb-with-like – ccheneson Nov 03 '14 at 15:58
  • Thanks but I know how to perform this query with the Mongo shell. It's a bit more complicated with the Opa language. – gogson Nov 03 '14 at 16:05

2 Answers2

2

The DbGen automation mechanism in Opa has support for this:

DbSet.iterator(/path/data[name =~ pattern])
Henri
  • 214
  • 2
  • 9
  • Thanks ! I didn't see it in the docs/book ! Now I found it in the source code ;) ([parser_path.trx](https://github.com/MLstate/opalang/blob/master/compiler/opalang/classic_syntax/parser_path.trx) and [pass_MongoAccessGeneration.ml](https://github.com/MLstate/opalang/blob/c9358f8f5648164515f1fe0e651ce0c1aa1e7a2e/compiler/opa/pass_MongoAccessGeneration.ml) files) – gogson Nov 03 '14 at 23:46
2

As @Henri pointed out there is regular expression searching support in Opa since commit [enhance] DbGen: add case insensitive regex operator =~ what is very nice.

Mind that it is using $regex operator, not the full-text index and it may result with some performance loss :( As MongoDB documentation says $regex operator uses indexes in limited way - only for prefix search: pattern ^Jean. Searching for Jean anywhere in text will require full scan.

Personally, I am using full-text index feature of Mongo with Opa's "low-level" API for the $text command like this:

  function list({float score, Article.id id}) textSearch(string query) {
    function onfailure(failure) {
      cat.error("textSearch({{~query}}): {failure}");
      [];
    }
    function onsuccess(success) {
      function aux(~{name,value}) {
        name == "results";
      }
      match (List.filter(aux, success)) {
      | [] :
        // `results` field not found - error
        onfailure(success);
      | results:
        cat.debug("textSearch({~{query}}): {results}");
        function ({~score, obj: ~{id}}) {
          ~{score, id}
        }
        |> List.map(_, Bson.doc2opa(results) ? []);
      }
    }

    opts = [H.str("search", query), H.doc("project", [H.i32("_id",0), H.i32("id",1)])];
    //  { search: query, project: {_id:0, id:1}, }
    //  |> Bson.opa2doc
    outcome = MongoCommands.simple_str_command_opts(ll_db, db_name, "text", coll_name, opts);
    MongoCommon.outcome_map(outcome, onsuccess, onfailure)
  }

Feature is available in Mongo since 2.4 as experimental (you have to turn it on by special configuration option) and in 2.6 as stable (turned on by default).

Marcin Skórzewski
  • 2,854
  • 1
  • 17
  • 27
  • Thanks Marcin. We will probably bind the `$text` command as well. If you want to submit a pull request along the lines of the commit you refer to, we'll accept it gladly. – Henri Nov 10 '14 at 13:46
  • I still did not migrate my database to the release 2.6. There are some problems with the indices in my application. After addition of some index (in 2.4) query is interpreted in a different way and limit of number of documents returned is not working any more. It probably is linked with the MongoDB limitation on the multi-key indices. Curiously, set database working well with 2.4 is behaving the same way (w/o additional index) in 2.6. When I will solve this problem I will migrate application to the `$text` query operator (available since 2.6) from my current `text` command (deprecated in 2.6). – Marcin Skórzewski Nov 24 '14 at 16:04