-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: Column Store
-
Storage Engines, Storage Engines - Transactions
-
StorEng - Defined Pipeline
-
None
For FLCS, we expect search_near and search to behave the same way for implicit records. For example, if we have the following records:
1 <some_value> 2 <some_value> ... gap ... 10 <some_value>
Doing a search or search_near on a record that is part of the gap, we should find the key but return a value of 0 that shows the record is implicit / deleted.
The following diff exposes a bug:
diff --git a/test/suite/test_bug001.py b/test/suite/test_bug001.py index af43a5ee4..bb47ad079 100644 --- a/test/suite/test_bug001.py +++ b/test/suite/test_bug001.py @@ -57,9 +57,13 @@ class test_bug001(wttest.WiredTigerTestCase): for i in range(0, 5): self.assertEqual(cursor[60 + i], 0x00) + # The test passes after re-opening the connection. + # self.reopen_conn() + # cursor = self.session.open_cursor(uri, None) + # Check cursor next inside trailing implicit keys. cursor.set_key(60) - self.assertEqual(cursor.search(), 0) + self.assertEqual(cursor.search_near(), 0) for i in range(0, 5): self.assertEqual(cursor.get_key(), 60 + i) self.assertEqual(cursor.get_value(), 0x00)
The search_near returns 1 instead of 0 and positions itself on the next valid record. If the connection is re-opened and everything is written to disk, search_near does find the implicit record.
- is related to
-
-
- Closed
-