[SERVER-18074] Provide way to specify field order in $project or use field order listed in project spec Created: 15/Apr/15 Updated: 30/Jun/19 Resolved: 30/Jun/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | William Berkeley | Assignee: | Asya Kamsky |
| Resolution: | Done | Votes: | 15 |
| Labels: | expression, usability | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
There've been requests for preserving field order that $project gives, i.e. if it specifies field3:1, field1:1, newField:{something}, field0:1 then it's desired for the fields to be in that specific order in the result. Original summary: Original Description: Best explained by example:
Simple workaround is to swap fields by rename them in the projection, then renaming the fields back to their original names in another project, but still this seems like incorrect behavior because the order of keys in an embedded object is meaningful. |
| Comments |
| Comment by Asya Kamsky [ 30/Jun/19 ] | |||||||||
|
This can be achieved by using $replaceWith rather than $project to construct the new document. New in 4.2 it's an alias for $replaceRoot which has existed since 3.4. All fields $replaceRoot/$replaceWith specify will be included in exact given order. There is no implicit carry-forward of `_id` field so it has to be specified explicitly same as all other fields if it's desired. | |||||||||
| Comment by Charlie Swanson [ 04/Jun/19 ] | |||||||||
|
Re-flagging for scheduling to discuss with the team. I think we may want to close this now that we added $replaceWith as a pretty easy workaround. | |||||||||
| Comment by Charlie Swanson [ 03/Jan/17 ] | |||||||||
|
As of version 3.4, I believe the following can be used as a workaround, provided you know which fields you need. The new $replaceRoot stage will output the documents with the fields in the order given. Thus, if you know you need only fields a, b, and c, you can get them in that order by doing the following:
| |||||||||
| Comment by tisha Kariya [ 22/Dec/16 ] | |||||||||
|
being affected by this issue forced to find work around. Please fix soon. | |||||||||
| Comment by John A. De Goes [ 07/Jul/16 ] | |||||||||
|
Martin: Please be sure to up-vote this ticket! Also, SlamData will have a workaround for this behavior in 3.1, but it will be slower because it requires 2 additional layers of useless projects to workaround. | |||||||||
| Comment by Martin Higham [ 07/Jul/16 ] | |||||||||
|
+1; Scott describes the problem perfectly. It's crazy | |||||||||
| Comment by Scott Chung [ 07/Jan/16 ] | |||||||||
|
+1; | |||||||||
| Comment by Andrew Maxwell [ 16/Jun/15 ] | |||||||||
|
I would really appreciate that this issue get some attention. My company is looking into 3rd party tools to help us wander through and observe our data more efficiently. One particular tool of interest is SlamData which is being directly affected by this issue. | |||||||||
| Comment by John A. De Goes [ 16/Jun/15 ] | |||||||||
|
:+1: This feature would be very beneficial to the SlamData open source project, which compiles SQL to MongoDB. Currently, we cannot always guarantee that the order of fields in a result set matches the order specified in a SELECT cause, which is inconvenient for users and potentially incompatible with BI tools (which expect that guarantee). We can work around this by introducing an intermediate $project which renames everything to temp names, and then a final one which renames it back, but this leads to slower queries. | |||||||||
| Comment by Asya Kamsky [ 16/Jun/15 ] | |||||||||
|
Reopened and changed title and description to request behavior that we currently don't have. | |||||||||
| Comment by Charlie Swanson [ 20/May/15 ] | |||||||||
|
We do not guarantee the order of the fields output by a $project stage. |