[SERVER-2150] Persistent Queries Created: 26/Nov/10  Updated: 06/Dec/22  Resolved: 17/Dec/18

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Alexandru Ioan Turc Assignee: Backlog - Query Team (Inactive)
Resolution: Duplicate Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-27698 Materialized Views Backlog
depends on SERVER-13932 Change Notification Stream API Closed
Duplicate
duplicates SERVER-31720 Provide a way to get notification whe... Backlog
is duplicated by SERVER-38401 Provide a way to determine if the res... Closed
Assigned Teams:
Query
Participants:

 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.



 Comments   
Comment by Asya Kamsky [ 17/Dec/18 ]

Because SERVER-31720 has more current description of functionality this ticket is describing, I'm closing this ticket in favor of the later one rather than the other way around.

 

Generated at Thu Feb 08 02:59:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.