[SERVER-25159] Default BSON validation version should depend on admin.system.version Created: 19/Jul/16  Updated: 19/Nov/16  Resolved: 02/Sep/16

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Querying
Affects Version/s: None
Fix Version/s: 3.3.14

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-25155 Create setFeatureCompatibilityVersion... Closed
Backwards Compatibility: Fully Compatible
Sprint: Query 2016-08-29, Query 2016-09-19
Participants:

 Description   

If version in admin.system.version is < 3.4, validate database commands using BSON 1.0 and reject commands including decimals (essentially enableBSON1_1=false).



 Comments   
Comment by Githook User [ 02/Sep/16 ]

Author:

{u'username': u'tessavitabile', u'name': u'Tess Avitabile', u'email': u'tess.avitabile@mongodb.com'}

Message: SERVER-25159 Default BSON validation version should depend on admin.system.version
Branch: master
https://github.com/mongodb/mongo/commit/f288ea86db58c6aefe4807ed7ac1815577da2752

Comment by Andy Schwerin [ 20/Jul/16 ]

I agree re caching the value. That will require a little work, since you'll need to observe writes to the admin.system.version document to refresh the cache.

Comment by Geert Bosch [ 19/Jul/16 ]

We'd cache the minVersion setting. Reading the variable should be practically free.

Comment by Tess Avitabile (Inactive) [ 19/Jul/16 ]

schwerin geert.bosch Do you think this will be sufficiently fast? Or if it isn't, is there anything we can do instead?

Also, since we're checking admin.system.version on every command anyway, should we reject queries with collation if the version is < 3.4? This would prevent issues where you issue a query with collation and the set of results returned/modified is different depending on whether the primary is 3.4 or 3.2.

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