[SERVER-32759] Add the support to insert a value into the new unique index format Created: 18/Jan/18  Updated: 30/Oct/23  Resolved: 22/Feb/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 3.7.3

Type: Improvement Priority: Major - P3
Reporter: Neha Khatri Assignee: Neha Khatri
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-28619 Implement new duplicate unique key ha... Closed
Related
related to SERVER-32760 Add the support to read from the new ... Closed
is related to SERVER-32820 Support new unique index format durin... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage 2018-02-12, Storage 2018-02-26
Participants:

 Description   

The schema for the new index format would match the existing non-unique format. The unique constraint checking would be done in the integration layer rather than relying on WiredTiger. For an insert operation into new unique index implement the Unique Index Constraint checking algorithm to guarantee the uniqueness.

The Unique Index Constraint checking algorithm is explained in the design.



 Comments   
Comment by Githook User [ 22/Feb/18 ]

Author:

{'email': 'neha.khatr@mongodb.com', 'name': 'nehakhatri5'}

Message: SERVER-32759 Insert, remove and read support for new unique index format.

Added insert, remove and read support for the new index format.
Disabled new index format for _id index.
Support new format inserts on secondary too.
Branch: master
https://github.com/mongodb/mongo/commit/8e67bade9a4acb7688895a59645034babb71f7c0

Comment by Eric Milkie [ 12/Feb/18 ]

Good question; I think you should add new functionality to KeyString to extract a Key.

Comment by Neha Khatri [ 12/Feb/18 ]

milkie When we insert a key into a unique index with the new format, first we would try to search for that key in the table using WT search_near. This might return an adjacent record rather than an exact match. The key of that adjacent record can be extracted using get_key API. However this key would be of format ({ 10.0 }, RecordId 5). To be able to detect a conflicting insert we should be able to extract {10.0} part from the key.

Currently there is function KeyString::decodeRecordIdAtEnd(const void* bufferRaw, size_t bufSize) to extract the RecordID from a key string. Is it possible to decode the Key in similar way?

One way to detect the duplicate key would be to decode Key from the Key buffer returned by get_key.

Another way of detection is:

  • Decode the RecordId (decodedId) from the Key returned by search_near using decodeRecordIdAtEnd.
  • Compose a new KeyString newKey(key, decodedId ).
  • Compare the composed KeyString buffer and Key buffer(WT_ITEM) returned by search_near.

    std::memcmp(newKey.getBuffer(), item.data, newKey.getSize()) == 0
    

    A match indicates duplicate key.

Generated at Thu Feb 08 04:31:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.