[SERVER-46251] Enable fsm workloads to work over multiple collections Created: 19/Feb/20  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Concurrency, Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Charlie Swanson Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Unresolved Votes: 0
Labels: fsm-new-feature
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Tooling & Methods
Participants:

 Description   

When adding some tests for $unionWith, it became clear the framework is all built around the one collection with the unique name. In order to better integrate testing things like $unionwith into the framework, we should be able to opt-in to having the test operate on multiple namespaces. This would allow:

  1. benefitting from the test setup, including things like sharding the collection.
  2. Plug in better to simultaneous variants - letting the test infrastructure know about all the collections involved
  3. Make things easier to manage for the infrastructure and test authors. For example, this code should probably know of all used collections.


 Comments   
Comment by Steven Vannelli [ 10/May/22 ]

Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions.

Comment by Robert Guo (Inactive) [ 06/Aug/20 ]

Moving it to the backlog for now since there is a workaround; if there's additional functionality you'd like, feel free to comment on this ticket.

Comment by Robert Guo (Inactive) [ 21/May/20 ]

charlie.swanson This feature might be too well hidden, but you can pass in TestData.sameCollection = false and TestData.sameDB = false to allow each thread to use a separate NS. You can also shard if not using the same collection.

Cleanup is not automatic but you can have the workload's teardown() function take care of dropping additional collections created for $unionwith.

Let me know if the above seems reasonable. Happy to provide a more detailed example if you'd like.

Generated at Thu Feb 08 05:10:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.