[SERVER-28778] Multiversion testing for array updates Created: 12/Apr/17  Updated: 02/Aug/17  Resolved: 02/Aug/17

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Depends
depends on SERVER-28763 Create UpdateArrayNode Closed
Sprint: Query 2017-08-21
Participants:

 Description   

A 3.4 primary should error when it receives array updates. A 3.6 primary should succeed when it receives array updates, and the updates should correctly replicate to a 3.4 secondary.



 Comments   
Comment by David Storch [ 02/Aug/17 ]

tess.avitabile sounds good, I've closed this ticket as "Won't Fix".

Comment by Tess Avitabile (Inactive) [ 01/Aug/17 ]

I'm not sure what we would test, since we know that the arrayFilters feature is controlled by featureCompatibilityVersion, due to arrayFilters_feature_compatibility_version.js. We do have the sharding_last_stable_mongos_and_mixed_shards passthrough, which tests mixed shards (though not mixed replica sets). mixed_storage_version_replication.js tests updates in mixed-version replica sets. upgrade_cluster.js tests CRUD operations between each stage of a normal upgrade procedure. I've filed SERVER-30440 about a featureCompatibilityVersion=3.4 passthrough to ensure we have test coverage for the old update system on 3.6.

Comment by David Storch [ 01/Aug/17 ]

I'm not really concerned about that scenario either. The more important question is whether we think it's worth the time writing a test case to verify that everything works as we believe it should work. Maybe there's not a lot of value there? Presumably there are other multiversion tests which run updates in mixed version configurations?

Comment by Tess Avitabile (Inactive) [ 31/Jul/17 ]

That is a good question about validation rules. One validation rule became stricter: you can no longer $unset a field that is a required part of a DBRef. I've added this to my list of update system changes that should be documented in the release notes.

I'm not concerned about the case with a 3.4 mongos and a 3.6 mongod, because the featureCompatibilityVersion must be 3.4 in that scenario, so the arrayFilters feature will not be allowed and the old update system will be used.

Comment by David Storch [ 31/Jul/17 ]

tess.avitabile, everything above sounds good, though it might be worth brainstorming a little to think whether this project has any other upgrade/downgrade implications before closing. For example:

  • Did your work on validation change the rules at all for what is valid? Stricter rules could break old applications, but looser rules could prevent downgrade.
  • Could anything bad happen if you're using a 3.4 mongos with a 3.6 mongod? Would it be worthwhile to write a test verifying the behavior in this scenario?
Comment by Tess Avitabile (Inactive) [ 31/Jul/17 ]

david.storch, I would like to close this ticket as Won't Fix. Since the array filters are now guarded under featureCompatibilityVersion, it is no longer necessary to test that array updates to a 3.6 primary correctly replicate to 3.4 secondaries. We test that array filters are guarded under featureCompatibilityVersion in arrayFilters_feature_compatibility_version.js.

For the scenario where there is a 3.4 primary, it is easy to verify that the update command rejects the arrayFilters option on 3.4, and that array filter identifiers are treated as fieldnames.

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