Sending default read concern to the server

[petr-buchin]

From what I read in MongoDB Driver Specifications, driver must omit default read concern, if specified. As far as I understand, the default read concern in PHP can be obtained as follows:

$readConcern = new \MongoDB\Driver\ReadConcern();
null === $readConcern->getLevel(); // true

// or:

$readConcern = (new \MongoDB\Driver\Manager())->getReadConcern();
null === $readConcern->getLevel(); // true

But from what I see in a code of this library , the default read concern can be sent to the server by the library.
For example:

// \MongoDB\Driver\Manager instance is created internally in Client's constructor
$client = new \MongoDB\Client();

// By default, Database instance will inherit read concern from \MongoDB\Driver\Manager instance,
// constructed in Client's constructor. Collection instance will inherit readConcern, writeConcern
// and readPreference from Database. This means that $collection->readConcern for now contains
// default read concern.
$collection = $client->selectDatabase('test')->selectCollection('test');

// Find operation will inherit "readConcern" option from Collection. Thus, default read concern
// will not be omitted and will be sent to the server.
$cursor = $collection->find([]);

So I have a question whether this is an expected behavior or should this behavior be fixed.
Does the low-level driver remove default read concern and write concern before sending a query to the MongoDB server?
It worth noting, that the same logic applies to the write concern and writing commands, i.e. default write concern can be sent to the server with writing commands.

[jmikola]

Does the low-level driver remove default read concern and write concern before sending a query to the MongoDB server?

libmongoc always omits applying a default read concern (e.g. { }) to queries, based on mongodb/mongo-c-driver@3e34af3 (for CDRIVER-1527).

2017-01-17T16:53:46.082-0500 I COMMAND  [conn2] command test.foo command: find { find: "foo", filter: {}, limit: 1 } planSummary: COLLSCAN keysExamined:0 docsExamined:1 cursorExhausted:1 numYields:0 nreturned:1 reslen:135 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 0ms

---

It worth noting, that the same logic applies to the write concern and writing commands, i.e. default write concern can be sent to the server with writing commands.

This does appear to be an issue with write concerns, despite CDRIVER-1322 having a function to detect default write concerns. The logic in mongodb/mongo-c-driver@3e34af3#diff-f056549fad972eba9c93b7e0dcd9542bR1414 (also for CDRIVER-1527) appears to include a default write concern so long as the option is specified. Since PHPLIB always provides the option, we do see it sent across the wire:

2017-01-17T16:40:59.966-0500 I COMMAND  [conn1] command test.foo command: insert { insert: "foo", writeConcern: {}, ordered: true, documents: [ { x: 1, _id: ObjectId('587e8f6b6118fd4a0c5acbf2') } ] } ninserted:1 keysInserted:1 numYields:0 reslen:44 locks:{ Global: { acquireCount: { r: 3, w: 3 } }, Database: { acquireCount: { w: 2, W: 1 } }, Collection: { acquireCount: { w: 2 } } } protocol:op_query 3ms
...
2017-01-17T16:45:33.064-0500 I COMMAND  [conn2] command test.foo command: findAndModify { findAndModify: "foo", new: false, upsert: false, query: { x: 1 }, update: { $set: { y: 1 } }, writeConcern: {} } planSummary: COLLSCAN update: { $set: { y: 1 } } keysExamined:0 docsExamined:1 nMatched:1 nModified:1 numYields:0 reslen:120 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } } } protocol:op_query 0ms

I'll look into this further and create related JIRA issues as needed. Thanks for the report!

[petr-buchin]

@jmikola, thanks for the answer!
Do I understand correctly, that the issue with the write concern will be fixed in low-level driver, not in this library?

[jmikola]

Do I understand correctly, that the issue with the write concern will be fixed in low-level driver, not in this library?

I would like to address this in both places if possible. If the library can have a notion of an unset read concern, read preference, and write concern, that would allow us to not pass that around to the selected objects (e.g. Database, Collection, Bucket) and inject it into each operation.

That said, if the write concern is still considered to be in a "default" state by libmongoc, which I expect it may be if ultimately sourced from a vanilla client object, it may be a unintentionally including it in its operations. That would be a bug we could address.

[marliotto]

I have problem with readConcern.
I tried upgrade mongodb replica set from 3.0 to 3.2.
When I was upgrade secondary server, sometimes I catched exception "Read concern is not supported by the server executing this command", but I don't use readConcern.

My environment

Debian 8
PHP 5.6.29, php-fpm
mongodb/mongodb: 1.1.1
ext-mongodb: 1.2.5

Mongodb versions on replica set

primary: 3.0.14
secondary-1: 3.0.14
secondary-2: 3.2.12

[marliotto]

I've found a bug on Collection:findOne(). We have double selectServer after 4c61d3c#diff-810cdcfdd8a6b9e1fc0d1e96d7786874R462

    public function findOne($filter = [], array $options = [])
    {
        if ( ! isset($options['readPreference'])) {
            $options['readPreference'] = $this->readPreference;
        }
        $server = $this->manager->selectServer($options['readPreference']);
        if ( ! isset($options['readConcern']) && \MongoDB\server_supports_feature($server, self::$wireVersionForReadConcern)) {
            $options['readConcern'] = $this->readConcern;
        }
        if ( ! isset($options['typeMap'])) {
            $options['typeMap'] = $this->typeMap;
        }
        $operation = new FindOne($this->databaseName, $this->collectionName, $filter, $options);
        $server = $this->manager->selectServer($options['readPreference']);
        return $operation->execute($server);
    }

[jmikola]

@marliotto: Thanks for pointing out that bug. I've opened PHPLIB-260 as a tracking ticket and will hope to get that fixed soon.

@petr-buchin: I realized that I never created a JIRA issue for the aforementioned idea of tracking unset read concern, read preference, and write concern options. I've just done so in PHPLIB-261 and hope to address that in 1.2.0.

[jmikola]

@marliotto: 1.0.5 and 1.1.2 have been released with a fix.

[jmikola]

Closing this as all related PHPLIB tickets have been resolved and released.