[CDRIVER-1031] ReadConcern should be inherited from a parent when not set Created: 03/Dec/15  Updated: 05/Feb/16  Resolved: 26/Jan/16

Status: Closed
Project: C Driver
Component/s: None
Affects Version/s: 1.3.0-beta0
Fix Version/s: 1.3.1, 1.3.2

Type: Bug Priority: Major - P3
Reporter: Samantha Ritter (Inactive) Assignee: A. Jesse Jiryu Davis
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by CXX-758 ReadConcern should be inherited from ... Closed
Related
is related to CDRIVER-1075 Generic command functions shouldn't u... Closed
is related to CDRIVER-837 Add support for the readConcern option Closed

 Description   

ReadConcern SHOULD be specifiable at the Client, Database, and Collection levels. Unless specified, the value MUST be inherited from its parent

When creating a collection, if no read_concern is provided, we'll create a new read_concern rather than inheriting from the parent database. The same is true for new databases.



 Comments   
Comment by Githook User [ 05/Feb/16 ]

Author:

{u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}

Message: CDRIVER-1031 mongoc_database_get_collection inherits config

Copy write concern, read concern, and read preference from database, not from the client.
Branch: r1.3
https://github.com/mongodb/mongo-c-driver/commit/717049338f0d9283b81cff67ad21c980bb44b872

Comment by Githook User [ 27/Jan/16 ]

Author:

{u'username': u'bjori', u'name': u'Hannes Magnusson', u'email': u'bjori@php.net'}

Message: Merge remote-tracking branch 'upstream/r1.3'

Comment by Githook User [ 27/Jan/16 ]

Author:

{u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}

Message: CDRIVER-1031 gridfs inherits client config
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/d2ec937364876ac0d4cfb2136ebde2753f0d4bbe

Comment by A. Jesse Jiryu Davis [ 26/Jan/16 ]

Thanks samantha.ritter, do you see any other mistakes?

Comment by Githook User [ 26/Jan/16 ]

Author:

{u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}

Message: CDRIVER-1031 mongoc_database_get_collection inherits config

Copy write concern, read concern, and read preference from database, not from the client.
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/cbad0acc37f7858c750991fc0559362f5809d2c7

Comment by Samantha Ritter (Inactive) [ 21/Jan/16 ]

Hey, this still isn't quite right. When using mongoc_database_get_collection() to create a new mongoc_collection_t for an existing database collection, the read concern is not plumbed through. In this method, we call mongoc_client_get_collection() without passing the database's read_concern down, and the new collection will have its parent client's read_concern instead of its parent database's.

Comment by Githook User [ 12/Jan/16 ]

Author:

{u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}

Message: CDRIVER-1031 gridfs inherits client config
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/3a49da4e7f687e3e2e7f190b9d3120765abc09ea

Comment by Githook User [ 12/Jan/16 ]

Author:

{u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}

Message: CDRIVER-1031 check gridfs inherits client config
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/1840cc8bf273aabae4f0f570a1284519aa69b9fe

Comment by A. Jesse Jiryu Davis [ 07/Jan/16 ]

We should follow the spec. Read pref and read / write concern should be copied from the client.

Comment by Samantha Ritter (Inactive) [ 06/Jan/16 ]

from the gridfs spec:

writeConcern: defaults to the write concern on the parent database (or client object if the parent database has no write concern).
readPreference: defaults to the read preference on the parent database (or client object if the parent database has no read preference).

Since there is no db object in the c driver's gridfs, should it be the client's then? I think the gridfs spec was written before read_concern was a thing, but I imagine the same would apply for that?

Comment by Hannes Magnusson [ 05/Jan/16 ]

Isn't GridFS special in that it is explicitly not allowed to inherit anything?
It must use w: 1, and readPrferenes primary?

You have a point regarding the read_concern though. I don't think how to deal with that is mentioned anywhere.

Comment by Samantha Ritter (Inactive) [ 04/Jan/16 ]

I didn't look closely enough at the "db" parameter to _mongoc_collection_new(), I didn't realize it was just the db name. Regardless, I think there's something off here.

If parents are supposed to pass in their read_concern (or write_concern, read prefs etc) when they call _mongoc_database/collection_new(), I'm confused about why those methods accept NULL as a valid option for these parameters. There are places in the codebase that call _mongoc_collection_new() without passing a read_concern in, for example here in gridfs. In places like this, the new collection won't inherit its parent db's or client's read_concern, it will just get a new default read_concern. In gridfs, it seems like the client's read_concern should be passed in, the way it is in mongoc_client_get_collection().

In _mongoc_database_new(), there is always a handle to the parent client object, it seems like this method should always take the client's read_concern, write_concern, and read_prefs unless those are explicitly passed in. Currently, if they are not passed in, we create new default values for those.

Comment by Hannes Magnusson [ 03/Dec/15 ]

The _mongoc_[database|collection]_new() methods are private API and are called from the "parent" which passes its readConcer/writeConcern/readPreferences as default.

For example, _mongoc_database_new () is called by mongoc_client_get_database () which will pass the client->read_concern as the default value, so the created database will "inherit" the clients read[concern|preferences] and writeconcern

Generated at Wed Feb 07 21:11:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.