• Type: Icon: New Feature New Feature
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Querying
    • Labels:
      None
    • Query

      Let's say we have this query which returns all the documents in the collection 'users' where 'last_name' field has the value 'Smith':

      BasicDBObject query = new BasicDBObject();
      query.put("last_name", "Smith");
      DBCursor cursor = users.find(query);
      while(cursor.hasNext()) {
      System.out.println(cursor.next());
      }

      We might be interested in monitoring if the results of the above query change. At the moment the only solution is to periodically run the query again and decide the application level if something changes. This model is very ineffective if there are many clients.

      The solution I suggest is to implement "Persistent Queries", a feature which is usually found in directory servers (Active Directory, OpenDS, etc.). We should be able to register a listener for a given query and whenever the results of a query changed (ideal case) or might have changed (would be a signal at least) we should be notified.

      The listener should be notified with the cursor (might be too much) or at least with the signal that something might have changed with the results of the query (and the client applications would decide if and when to re-query). The signal might be a light solution and if changes are frequent the client canned decide not to re-run the query on every signal.

      As syntax, for the Java driver, might be:

      listener = new QueryListener() {
      public void resultChanged(BasicDBObject query, DBCursor cursor)

      { ... }


      }
      users.addQueryListener(query, listener)

      I'm not sure about how widespread is the need for something like this and I'm not sure what are the implementation complexities, but definitely at server level there is the most knowledge about when query might have been affected by a change.

      Definitely is not something to use when results might be large, we would not do repeated pooling either for large results. But might be very useful when the results are relatively small, change infrequent but is important to know when they changed.

      I would definitely find good use for something like this since subscription based models tend to be more efficient.

            Assignee:
            backlog-server-query Backlog - Query Team (Inactive)
            Reporter:
            alex.turc Alexandru Ioan Turc
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: