[SERVER-17943] add $filter expression to $project to work with $map and $reduce Created: 08/Apr/15 Updated: 17/Jan/18 Resolved: 07/May/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | 3.1.3 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Asya Kamsky | Assignee: | Charlie Swanson |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||
| Sprint: | Quint Iteration 3 | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Description |
|
Similar to $map (and in combination with possible $reduce |
| Comments |
| Comment by Asya Kamsky [ 25/Aug/15 ] |
|
My apologies, I was too terse in my description. When I said "new features" I meant that a general rule about whether to backport any feature is whether it's a new user facing feature that requires the drivers (among other things) to provide support for it. While I understand that new aggregation operator can be used without special support from the drivers, nonetheless our new feature checklist includes noting whether drivers need to add any specific support for the feature (as an example, see I understand your frustration when you see that a relatively isolated new functionality is added to a component in the upcoming version that you may badly need in the current version - but consider the amount of work required if part of adding this new feature included refactoring or improving parts of our test framework and there isn't a way to backport the feature with its tests without making major changes to current code. Worse yet may be if the new feature turns out to have some very bad performance side-effect or even cause a crash - it's much simpler to manage that just in the version that the feature is released in, especially since this new feature won't be released to users till 3.2 is GA. I don't believe that we are unique in this approach - patch or dot releases are meant for only minor changes, usually reserved for bug fixes, performance optimizations, security patches and such. Asya Kamsky |
| Comment by Oleg Rekutin [ 24/Aug/15 ] |
|
asya, I apologize if this is not an appropriate place to register this comment, but could you please ask MongoDB leadership to reflect on this "no new features" policy. I've noticed many a regression in WiredTiger performance or functionality (just look at all the 3.0.x releases, specifically this new 3.0.6 release and the things that it fixes). E.g. the side effect of fixing $filter and $arrayElemAt ( These are lightweight, low-complexity, low-risk backports that enable aggregations that are simply impossible in anything other than 3.1. Alternatives in 3.0 and below are MapReduce (too slow) and "$unwind/$group by $id" stages, which is an expensive group that has performance limits. My main point is that since the development process is not actually producing a 3.0.x branch that's sufficiently stable release-to-release, then it's a shame/unfortunate to watch small, but very useful features get left behind into a future 3.2.x release (including all the waiting time for the 3.2.x branch to be truly production-ready with a few point releases under its belt). Anyway, if anyone is interested in building your own backports: 3.0 backport: https://github.com/evergage/mongo/commit/be4e427de6df5ebe81016fe87f3a12af80782437 |
| Comment by Asya Kamsky [ 20/Aug/15 ] |
|
Unfortunately not - we can't back port completely new features. |
| Comment by Oleg Rekutin [ 20/May/15 ] |
|
Is this something that would be considered as a backport to 3.0 or 2.6 series? |
| Comment by Githook User [ 07/May/15 ] |
|
Author: {u'username': u'cswanson310', u'name': u'Charlie Swanson', u'email': u'cswanson310@gmail.com'}Message: |