[SERVER-828] Support for selecting array elements in return specifier (projection) Created: 25/Mar/10 Updated: 06/Apr/23 Resolved: 15/Jun/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.2 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Michael Dirolf | Assignee: | Ben Becker |
| Resolution: | Done | Votes: | 172 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
useful when querying on an embedded array and only wanting the matching element returned. leaving to eliot to decide version |
| Comments |
| Comment by akilesh heerah [ 26/Oct/20 ] | ||||||||
|
@Joseff Betancourt Hello , Have you able to find a solution to return all the matches element ? | ||||||||
| Comment by Dissatisfied Former User [ 28/Mar/13 ] | ||||||||
|
The implemented solution is not the solution to this ticket. The user expectation here was of, in effect, handling the child array as a collection, returning multiple filtered results from that "child collection". The implemented solution works for the translation use case, but not for the use case of returning a document whose child array contains only active-flagged sub-documents. (My use case.) | ||||||||
| Comment by Adam Crabtree [ 28/Jan/13 ] | ||||||||
|
Sorry if this is not an appropriate place for comment, but the description for the issue and the implemented solution seem to be a mismatch. I think what most people are hoping for is something like the $elemMatch projection, but for all matching array elements, not just the first. The reason it seems confusing and inconsistent probably has something to do with the $elemMatch selector returning multiple documents that match, whereas the projection returns only 1 element that matches. Confusion aside, is there any plan or existing issues that could be linked to to allow projections for array subsets? | ||||||||
| Comment by Joseff Betancourt [ 19/Oct/12 ] | ||||||||
|
$elemMatch only works on first match... what if I wanted all matches in the area field of following example. Should there be an option for pull all results? _id: ObjectId(), ], , ] ] ] | ||||||||
| Comment by Scott Hernandez (Inactive) [ 31/Aug/12 ] | ||||||||
|
Docs for $elemMatch (projection) are here: | ||||||||
| Comment by auto [ 30/Jul/12 ] | ||||||||
|
Author: {u'date': u'2012-07-27T20:11:08-07:00', u'email': u'jeff.yemin@10gen.com', u'name': u'Jeff Yemin'}Message: More tests for | ||||||||
| Comment by auto [ 15/Jun/12 ] | ||||||||
|
Author: {u'date': u'2012-06-15T15:04:27-07:00', u'email': u'ben.becker@10gen.com', u'name': u'Ben Becker'}Message: | ||||||||
| Comment by auto [ 15/Jun/12 ] | ||||||||
|
Author: {u'date': u'2012-06-15T15:04:27-07:00', u'email': u'ben.becker@10gen.com', u'name': u'Ben Becker'}Message: | ||||||||
| Comment by auto [ 15/Jun/12 ] | ||||||||
|
Author: {u'date': u'2012-06-15T15:04:27-07:00', u'email': u'ben.becker@10gen.com', u'name': u'Ben Becker'}Message: | ||||||||
| Comment by auto [ 15/Jun/12 ] | ||||||||
|
Author: {u'date': u'2012-06-15T15:04:27-07:00', u'email': u'ben.becker@10gen.com', u'name': u'Ben Becker'}Message: | ||||||||
| Comment by auto [ 15/Jun/12 ] | ||||||||
|
Author: {u'date': u'2012-06-15T10:47:32-07:00', u'email': u'ben.becker@10gen.com', u'name': u'Ben Becker'}Message: | ||||||||
| Comment by Ben Becker [ 15/Jun/12 ] | ||||||||
|
Note that | ||||||||
| Comment by Ben Becker [ 15/Jun/12 ] | ||||||||
|
Pushed while JIRA/aws was down: | ||||||||
| Comment by Colin Mollenhour [ 22/Feb/12 ] | ||||||||
|
@free, I'm fully aware that MongoDb is schema-free, I'm not sure what you're trying to say.. The JIRA is not a support forum so please continue discussion on the google group if needed, but here is the answer to your question:
Note that while the first $match is not necessary it will improve performance if either task.status is indexed or it is common that the set of documents that match will be smaller that the full set. See docs for explanation. I could be wrong, but the second match will not use an index although this could possibly be optimized later. Chris? | ||||||||
| Comment by free [ 22/Feb/12 ] | ||||||||
|
@Colin Mollenhour , {status:2}]} , {status:2}]} , {status:2}]} It's scheme-free mongodb,not mysql | ||||||||
| Comment by Colin Mollenhour [ 21/Feb/12 ] | ||||||||
|
@free Regarding performance I haven't done any large tests, but my basic test took 0ms (used shell to run command then profiler to get time in ms) so at least the overhead isn't high. I'm sure the aggregation framework will only continue to get faster as well. The primary concern to consider when using the aggregation framework is the size limit of the returned document (technically the results must fit in one document which is currently 16mb limit). However as long as your queries are sane I don't think this will be a problem. Here is a working test script (requires 2.1.0): https://gist.github.com/1879457 | ||||||||
| Comment by free [ 17/Feb/12 ] | ||||||||
|
@Colin Mollenhour | ||||||||
| Comment by Colin Mollenhour [ 14/Feb/12 ] | ||||||||
|
There are some caveats with this feature request. Some examples: If you want to filter the documents with one criteria (say "status") and the embedded documents by another (say "comments.timestamp") you run into the situation where maybe a document doesn't have any embedded documents that match but you still want the parent document in the results. Another is if you want to exclude certain fields like "changelog" but use the positional operator to include only matched embedded docs. Currently mixing includes and excludes is prohibited so you'd have to convert your excludes to includes on the application side. Thankfully, we have the aggregation framework now (2.1) which would let you filter parent documents independently of embedded documents and also use include/exclude on the parent document fields while still returning only matched embedded documents. The output can be made to match exactly what this feature request is asking for with far greater flexibility. Example:
So is this feature request now obsolete? | ||||||||
| Comment by Rodrigo Coelho [ 05/Jan/12 ] | ||||||||
|
Would be nice for my use case: multilanguage documents. | ||||||||
| Comment by Flavio Percoco [ 26/Sep/11 ] | ||||||||
|
@alex That's something you'll have to be aware of. If you have a collection that has documents with such arrays you'll have to be careful when retrieving those fields. AFAIT | ||||||||
| Comment by Alex Fomin [ 03/Jul/11 ] | ||||||||
|
And how about perfomance? | ||||||||
| Comment by M@ Keller [ 16/Jun/11 ] | ||||||||
|
This morning, actually, I lazily blogged about this before looking in Jira (which is not linked off the mongodb site that I could find, I had to use Google). | ||||||||
| Comment by Chris Westin [ 15/Jun/11 ] | ||||||||
|
The use of $unwind in the new aggregation framework will make it possible to be selective about which of several descendant objects are returned. | ||||||||
| Comment by Keith Branton [ 30/Apr/11 ] | ||||||||
|
Also... will this work if I need one document from one array and one from another array - in the same query - or would I have to do two queries? | ||||||||
| Comment by Keith Branton [ 30/Apr/11 ] | ||||||||
|
Will this be able to return several embedded documents if $in is used in the query? Being able to bring back only one is a huge win over current behavior, but being able to bring back all the ones I want (but only the ones I want) in a single query - now that would be cool! | ||||||||
| Comment by Karoly Negyesi [ 28/Dec/10 ] | ||||||||
|
Yes, this would be very useful because sometimes you have quite big arrays (and with the planned 32MB you will have even bigger) and it's pointless to get all that and convert to a PHP structure. | ||||||||
| Comment by Wes [ 28/Apr/10 ] | ||||||||
|
It would be nice if a flag existed for indicating whether the whole matching branch or just the matching elements would be returned. Example of behavior shown at http://groups.google.com/group/mongodb-user/browse_thread/thread/a51dcffdea389ef4 | ||||||||
| Comment by Michael Dirolf [ 28/Mar/10 ] | ||||||||
|
Should think about whether this should just be done w/ virtual collections |