[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: |
|
||||||||
| 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 |
| 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:
|
| 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. |