[SERVER-36381] Serialize $out to old format if featureCompatibilityVersion is "4.0" Created: 31/Jul/18 Updated: 29/Oct/23 Resolved: 30/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Upgrade/Downgrade |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.3 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kyle Suarez | Assignee: | Charlie Swanson |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Query 2018-09-10 | ||||||||
| Participants: | |||||||||
| Description |
|
By "old format", I mean the format described here, where only a string with the name of the output collection is specified. This allows a binary version 4.2 mongod to play nicely with binary version 4.0 mongod servers in a mixed-version cluster. If any 4.2-only options are specified, an error should be thrown. As part of this ticket, we'll write tests for $out in the multiversion suite. |
| Comments |
| Comment by Kyle Suarez [ 30/Aug/18 ] |
|
We just wanted to point out that unlike what we initially mentioned in the design, we do not have to perform a featureCompatibilityVersion check when serializing $out. The only time this would matter is during mongos serialization of a sharded $out aggregation, but our recommended practice is to upgrade the mongos last when upgrading a sharded cluster. |
| Comment by Githook User [ 30/Aug/18 ] |
|
Author: {'name': 'Charlie Swanson', 'email': 'charlie.swanson@mongodb.com', 'username': 'cswanson310'}Message: |