[SERVER-5378] Position of parameters within out {} object shouldn't matter Created: 23/Mar/12  Updated: 11/Nov/14  Resolved: 01/Jul/14

Status: Closed
Project: Core Server
Component/s: MapReduce
Affects Version/s: 2.1.0
Fix Version/s: 2.7.3

Type: Bug Priority: Minor - P4
Reporter: Ben Osheroff Assignee: Benety Goh
Resolution: Done Votes: 0
Labels: polish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File mr_parampositions.js     File pr192_rebase_ecfc44d.diff    
Issue Links:
Duplicate
is duplicated by SERVER-15023 mapReduce out option is order sensitive Closed
Related
is related to DOCS-3688 map reduce out parameter not longer r... Closed
Tested
Operating System: ALL
Participants:

 Description   

db.foo.mapReduce(... , ..., {out: {replace: "mr", db: "local"}}) 

should work the same as

db.foo.mapReduce(... , ..., {out: {db: "local", replace: "mr"}}) 

but the latter throws an error instead.



 Comments   
Comment by Benety Goh [ 01/Jul/14 ]

Attached JS test script from pull request. This JS test has been replaced by a C++ unit test.

Comment by Githook User [ 01/Jul/14 ]

Author:

{u'username': u'benety', u'name': u'Benety Goh', u'email': u'benety@mongodb.com'}

Message: SERVER-5378 replaced jstests/core/mr_parampositions.js with mr_test.cpp for out parameter field ordering
Branch: master
https://github.com/mongodb/mongo/commit/2d9368486aef3aee029ed46b7bd320e53c1ac3f4

Comment by Githook User [ 01/Jul/14 ]

Author:

{u'username': u'osheroff', u'name': u'osheroff', u'email': u'ben@zendesk.com'}

Message: SERVER-5378 out {} parameters position independence

Where we put replace, db, inline, etc within the map-reduce "out"
BSON object shouldn't matter

Signed-off-by: Benety Goh <benety@mongodb.com>
Branch: master
https://github.com/mongodb/mongo/commit/255d39c611877420112c3c2857cb11db49dc33a3

Comment by Githook User [ 01/Jul/14 ]

Author:

{u'username': u'benety', u'name': u'Benety Goh', u'email': u'benety@mongodb.com'}

Message: SERVER-5378 added tests for parsing map reduce output options
Branch: master
https://github.com/mongodb/mongo/commit/77f636c4606e01f28c1d8c6bb6606487ede2ffc8

Comment by Benety Goh [ 28/Jun/14 ]

rebased original pull request on commit ecfc44d7bce08660804fa4475b45f9a09d203f09

Comment by Ian Whalen (Inactive) [ 25/May/12 ]

@ben - in order to be able to integrate your pull request we'll need you to sign the contributor agreement at http://www.10gen.com/contributor - as soon as you've got that signed we'll be able to push forward on your pull request.

Comment by Antoine Girbal [ 11/Apr/12 ]

Ben,
thanks for presenting the issue from the practical point of view of ruby, it is a problem for unordered dictionaries.
Will look to integrate pull request

Comment by Ben Osheroff [ 04/Apr/12 ]

It's pretty unexpected behavior. A colleague and I beat our heads over a "WTF" moment for 15 minutes – we missed the one line "Note: ..." in the docs.

For another example, the ruby driver's map_reduce method:

  def map_reduce(map, reduce, opts={})
      ...
 
      hash = BSON::OrderedHash.new
 
      hash.merge! opts # BUG

Due to the fact that hashes have no guaranteed ordering within ruby, I can't simply write:

collection.map_reduce(..., ..., {:out => {:replace => "foo", :db => "bar", :sharded => true}})

but must instead write:

opts = {}
opts[:out] = BSON::OrderedHash.new
opts[:out][:replace] = "foo"
opts[:out][:db] = "bar"
opts[:out][:sharded] = false

Worse, if I use the first form, it may actually succeed in some cases due to the hash function dropping the parameters magically in the right order, but then start to fail randomly. I guess the driver could handle all of that for me, but clearly the driver writers don't know about this behavior either.

Anyway, I still don't see the benefit of the ordered-parameter behavior. What if my pull-request enforced that one and only one of [replace|merge|reduce|inline] appeared in the input?

Comment by Ben Osheroff [ 23/Mar/12 ]

https://github.com/mongodb/mongo/pull/192

Generated at Thu Feb 08 03:08:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.