-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
Fully Compatible
-
Execution Team 2024-03-04, Execution Team 2024-03-18, Execution Team 2024-04-01
We don't want to always use the recordId with dbHash. For example, if a customer has a recordIdsReplicated:false collection and then they upgrade to a repcordIdsReplicated:true collection, because dbHash includes the recordIds when calculating the hash in the latter case, the hash will be different, even if the documents on disk are exactly the same.
This can be confusing for customers if they run dbHash and get value X, upgrade and then get value, they might think that something has gotten corrupted on disk.
So we need to have a flag to make including the recordId opt-in. Likewise for SERVER-86692, the behavior of having dbHash include the natural order should be opt-in via this flag for the same reason. Otherwise someone who upgrades would see that the exact same capped collection was returning a different hash between versions.
- is related to
-
SERVER-78435 Scan in record id order for dbHash
- Closed
-
SERVER-86692 dbhash doesn't check natural order for capped collections with _id index
- Closed