mongodb - Mongo 2.4 - making db object available in server-side code (map/reduce) -

we started using mongo @ 2.0. part of queries run, run map/reduce jobs pull data other collections these jobs execute.

since mongo 2.4, functionality removed (http://docs.mongodb.org/manual/release-notes/2.4/#additional-limitations-for-map-reduce-and-where-operations), suggestion of "refactor code".

so, there way refactor code? know it's general question, asking general application. size , use of involved collections , cross-queries has enough variety.

at point, take patch brings db object server code scope. seems following patch sufficient (yes, understand has these security implications, i'm not using shards. it's quickest way regain functionality depend on):

diff --git a/src/mongo/db/commands/mr.cpp b/src/mongo/db/commands/mr.cpp index 742392f..225a2b7 100644 --- a/src/mongo/db/commands/mr.cpp +++ b/src/mongo/db/commands/mr.cpp @@ -623,6 +623,7 @@ namespace mongo {          void state::init() {              // setup js              _scope.reset(globalscriptengine->getpooledscope( _config.dbname, "mapreduce" ).release() ); +            _scope->localconnect( _config.dbname.c_str() );               if ( ! _config.scopesetup.isempty() )                  _scope->init( &_config.scopesetup ); 

conceptually, mapreduce operates on input document set , emitted values. performing db operation outside scope of mapreduce job, strictly speaking. more information on why change made, please see server-8104 , server-3130.

with said, supplied patch should work, caution against using due locking implications (and aforementioned security issues).

as generalized question of how refactor code may have utilized feature in past versions, 1 suggestion comes mind using multiple mapreduce jobs leverage 'reduce' output type. documentation incremental mapreduce may helpful here.

if goal server-side execution, option may refactor mapreduce logic script can executed using db.eval(). may complex exercise due nature of problem.