This ticket is a follow on work from
WT-7912. It is used to think of how to build stress tests for the prefix enabled search near functionality and create a stress test behind the ideas placed.
We want to stress test search_near with prefix key configured. This means the stress testing framework will need to perform repeated prefix search near calls and a validation module to count the number of records traversed and the key returned is correct. It is also beneficial to implement a unique index validation piece by simulating unique index insertions and counting that it doesn't insert documents that already exist in the index.
Update: There will be three tests that will be created to accommodate all cases in prefix search nears.
WT-8086 will be used to count the number of records traversed, this ticket WT-7924 will validate the prefix search near keys and WT-8091 will simulate unique index insertions.
Description of the test:
This ticket will create a cppsuite test which will validate that the prefix key search near returns the correct key. Prefix search near should only be returning keys that are within the prefix portion of the search key, e.g. "aa", can only return any keys in the tree that are prefixed "aa". Visibility rules also apply, this means a key should be returned only if it is visible at the time of the read.
This test will contain a set of insert threads that will insert randomly generated keys with a prefix of a -> z. There will also be a set of read threads that will perform prefix search nears, and a validation part to verify that the returned key by those threads is valid.
The validation part will be utilizing the search near API without the prefix_key configuration. There are many edge cases that need to be covered because search_near() with prefix_key enabled can actually return back different valid results than prefix search_near() without prefix_key enabled. Such edges cases are:
- A table with visible keys aba and aza, prefix search near has to return back aba, but search near without prefix_key configuration can potentially return back aza, as it is also a valid key. In this case, validation involves performing next calls() until we find the key "aba".
This test will also have user-configurable options to modify the stressing test. e.g. insert thread count, read thread count.