Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-2150

Persistent Queries

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Querying
    • Labels:
      None

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved: