[SERVER-610] Temp Collections for Non Map-Reduce Queries Created: 06/Feb/10 Updated: 06/Dec/22 Resolved: 17/May/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Durran Jordan | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Duplicate | Votes: | 6 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
All |
||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
I would like to request the ability to have the results of a query stored in a temporary collection without using Map/Reduce. The query could be executed and return the name of the temporary collection, and options could be passed to define options of the collection, for instance if it's capped or not. There are certain cases where this "query and forget until later" could be quite useful... For instance a long running operation over a large dataset where we don't expect results to get returned immediately. An example of this is providing a custom external DSL for users to perform queries against the database, but the DSL to Javascript translation would be an extremely large overhead in order to leverage Map/Reduce. The current workaround for this is to put the query on another long running background process and manually put the results in a new collection, I am just looking for a nice way to simplify this. |
| Comments |
| Comment by Asya Kamsky [ 17/May/17 ] |
|
This was resolved via "$out" capability of aggregation framework in 2.6 time frame. |
| Comment by Durran Jordan [ 16/May/17 ] |
|
Oh yeah - this can be closed as $out covers the use case. |
| Comment by Asya Kamsky [ 15/May/17 ] |
|
This seems like it can be closed since $out in aggregation allows doing what's described. |
| Comment by David Storch [ 03/Dec/15 ] |
|
durran, would you say that this is a duplicate of the aggregation framework's $out facility, added for 2.6 under |
| Comment by Kostyantin Voz [ 17/Mar/10 ] |
|
What if that collections won't be temp ? What if that will be [capped] collections working like views in CouchDB ? That could make possible such a thing : querying data from collection, than creating another collection to save the results, when new data added to source collection, it will be queried with the same query and than if match stored in target collection. |