[SERVER-28892] Test Causal Consistency in shell Created: 20/Apr/17 Updated: 30/Oct/23 Resolved: 04/May/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.7 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Misha Tyulenev | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 2017-05-08, Sharding 2017-05-29 |
| Participants: |
| Description |
|
Use ShardingTest to verify that CausalConsistency is supported by shell
|
| Comments |
| Comment by Githook User [ 04/May/17 ] |
|
Author: {u'username': u'jsmulrow', u'name': u'Jack Mulrow', u'email': u'jack.mulrow@mongodb.com'}Message: |
| Comment by Jack Mulrow [ 03/May/17 ] |
|
max.hirschhorn Oh ok that makes sense. I'll do that and then there won't be any need for manually setting logical times. |
| Comment by Max Hirschhorn [ 03/May/17 ] |
jack.mulrow, my point is that you can breaking up the behavior you're testing to (1) verify that the mongo shell forwards the operation time for all relevant commands and updates it based on the server's response, and (2) verify the server rejects the command when the operation time is invalid. The mongo shell doesn't have a notion of whether its operation time is valid (i.e. only the server does), so you don't get any benefit for testing #2 by modifying _operationTime directly rather than just running the command with an explicit "afterClusterTime" option. |
| Comment by Jack Mulrow [ 03/May/17 ] |
|
max.hirschhorn I'm fine with updating _operationTime and _clusterTime directly, I just wasn't sure if that was a best practice. So I won't add new methods then, I'll just update those properties directly. As for your second comment, this ticket is for testing that the methods added to the Mongo object by SERVER-28450, work as expected when _isCausal is true, so I can't put readConcern: {afterClusterTime: ... in the initial command because the test is making sure the shell adds it automatically for the commands enabled in SERVER-28869. Thanks! |
| Comment by Misha Tyulenev [ 27/Apr/17 ] |
|
max.hirschhorn its a good point, as we discussed offline - this can be split in 2 pieces: |
| Comment by Max Hirschhorn [ 25/Apr/17 ] |
|
misha.tyulenev, in addition to the test cases you've described, I think it would also be good to also test that the operation time for Mongo object initialized using a replica set connection string (e.g. the return value of ReplSetTest.prototype.getURL()) is forwarded from the primary's response to the secondary. |
| Comment by Misha Tyulenev [ 21/Apr/17 ] |
|
CC jack.mulrow |
| Comment by Misha Tyulenev [ 20/Apr/17 ] |
|
max.hirschhorn here is an outline of the test case for the API - as a reviewer of this test could you please take a look and ack the general concept leaving the details to the actual CR? |