Add support for passing options (or mongodb) to all methods.

[rudolph9]

Previously only methods that allowed the multi option supported
additional passed option. That change adds support for all other
methods, ultimately calling e.g. find, findAndModify

This indirectly address #127 as a MongoDB session can be via options (or mongodb). Allowing the user to do something like the following:

import { ObjectID } from 'mongodb'

export default async app => {
  app.use('/fooBarService', {
    async create(data) {
      // assumes you have access to the mongoClient via your app state
      let session = app.mongoClient.startSession()
      try {
        await session.withTransaction(async () => {
            let fooID = new ObjectID()
            let barID = new ObjectID()
            app.service('fooService').create(
              { 
                ...data,
                _id: fooID,
                bar: barID,
              },
              { mongodb: { session } },
            )
            app.service('barService').create(
              {
                ...data,
                _id: barID
                foo: fooID
              },
              { mongodb: { session } },
            )
        })
      } finally {
        await session.endSession()
      }
    }
  })
}

[rudolph9]

Please note, the linter flags a line of code unchanged by this pull request:

diff --git a/lib/index.js b/lib/index.js
index 1d2b990..8f7e917 100644
--- a/lib/index.js
+++ b/lib/index.js
@@ -226,7 +226,7 @@ class Service extends AdapterService {
     const remapModifier = this._remapModifiers(this._normalizeId(id, data));
 
     const idParams = Object.assign({}, params, {
-      paginate: false,
+      paginate: false
     });
 
     const ids = this._findOrGet(id, idParams)

[daedalus28]

This looks great and would be a big help when doing transactions. What are the next steps to get this merged @daffl?

[arlukin]

Great, I was about to push a pull request with similar code.

One thing that I did differently was to not pass options to estimatedDocumentCount and countDocuments. They don't have any session parameter. But all monodb operations have slightly different options. Have you tried to see what happens if for example countDocuments will get options.session? Will it just nicely ignore it?

Some links to documentation.
http://mongodb.github.io/node-mongodb-native/3.6/api/Collection.html#estimatedDocumentCount
http://mongodb.github.io/node-mongodb-native/3.6/api/Collection.html#countDocuments

[DaddyWarbucks]

This looks cool! I am not a maintainer, but I do contribute often to the DB adapters. I would suggest modifying your code such that it does not change the filterQuery method. That method is on almost all of the adapters and has the same function signature and return values in all of them. I would move the code to pull the options off params into its own method. I also suggest removing the params.options and just using params.mongodb

[daffl]

Yes, this makes sense, thank you for the for the pull request @rudolph9. This features needs to be added to the documentation in the Readme, other than that it looks good to me.

[rudolph9]

Great, I was about to push a pull request with similar code.

One thing that I did differently was to not pass options to estimatedDocumentCount and countDocuments. They don't have any session parameter. But all monodb operations have slightly different options. Have you tried to see what happens if for example countDocuments will get options.session? Will it just nicely ignore it?

Some links to documentation.
http://mongodb.github.io/node-mongodb-native/3.6/api/Collection.html#estimatedDocumentCount
http://mongodb.github.io/node-mongodb-native/3.6/api/Collection.html#countDocuments

Good thing to point out. It appears to ignore the session option on both.

[rudolph9]

@daffl Added documentation to the README.md. Please let me know if there are any other changes you would like to see.

[daffl]

Looks great. The only other question I had was if there is a reason to have two ways for passing it (via params.options and params.mongodb). Ideally there should only be one way to use a feature (unless for backwards compatibility reasons) and I'd find params.mongodb more clear.

[rudolph9]

@daffl

Looks great. The only other question I had was if there is a reason to have two ways for passing it (via params.options and params.mongodb). Ideally there should only be one way to use a feature (unless for backwards compatibility reasons) and I'd find params.mongodb more clear.

I agree, params.mongodb is more clear. The reason I did also did options was because the existing _multiOptions helper method was already doing so. The _options helper I wrote is mirror that.

https://github.com/feathersjs-ecosystem/feathers-mongodb/pull/189/files#diff-92bbac9a308cd5fcf9db165841f2d90ce981baddcb2b1e26cfff170929af3bd1R42

I think we want _options and _multiOptions to be consistent and also not make any breaking changes but obviously this isn't ideal because we're supporting both options and mongodb fields.

In any case, I defer to you to decide how to move forward?

[daffl]

I think that makes sense. Released as v6.3.0, thank you again!