[SERVER-6084] Map/Reduce, emit() should not allow undefined as key Created: 13/Jun/12 Updated: 06/Dec/22 Resolved: 04/Feb/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MapReduce |
| Affects Version/s: | 2.0.6 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Trivial - P5 |
| Reporter: | Andy Davis | Assignee: | Backlog - Query Optimization |
| Resolution: | Done | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
OSX (not sure if that's relevant) |
||
| Assigned Teams: |
Query Optimization
|
| Participants: |
| Description |
|
The map function allows emit() to emit an undefined value for the key. When many such emits occur, the reduce step will fail complaining that the value is too large to reduce. I can't see a situation where I would ever want to allow a key to be undefined, so I would like emit to throw an exception on the emit(). If changing the default behavior is undesirable, some sort of 'strict' flag that enforced this would be nice. Personally, I ran into this because I ran a new M/R against an old collection. I don't see it as a big deal for production systems, but at least the option to fail fast might speed up the development cycle. |
| Comments |
| Comment by Esha Bhargava [ 04/Feb/22 ] |
|
Closing these tickets as part of the deprecation of mapReduce. |
| Comment by David Storch [ 16/Aug/19 ] |
|
It appears that in the master branch, emit() is still allowed to produce undefined as a key. However, we end up storing an _id of null rather than undefined in the resulting output collection. |
| Comment by Antoine Girbal [ 09/Jul/12 ] |
|
we cannot change the default existing behavior since it could break some systems. |