[SERVER-78574] Refactor RecordStore::ns to return a NamespaceString object Created: 30/Jun/23  Updated: 29/Oct/23  Resolved: 07/Jul/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Mathis Bessa Assignee: Mathis Bessa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-74490 Change NamespaceString::ns() to be pr... Closed
Related
is related to SERVER-78731 Remove the ns() method on the RecordS... Backlog
Backwards Compatibility: Fully Compatible
Sprint: Server Serverless 2023-07-10
Participants:

 Description   

WiredTigerRecordStore::ns is currently returning a string after we serialize from a string.

That returned string object from `ns()` is then used for logging purposes.

We should refactor the method to return a NamespaceString object directly and then use `toStringForLogging` or `toStringForErrorMessage` when needed.

 



 Comments   
Comment by Githook User [ 07/Jul/23 ]

Author:

{'name': 'mathisbessamdb', 'email': 'mathis.bessa@mongodb.com', 'username': 'mathisbessamdb'}

Message: SERVER-78574 Refactor RecordStore::ns to return a NamespaceString object
Branch: master
https://github.com/mongodb/mongo/commit/624f572173dd01001614750a68b5a5173d11d626

Comment by Mathis Bessa [ 06/Jul/23 ]

kaloian.manassiev@mongodb.com I have created SERVER-78731 to address your comment and assigned it to Storage Execution EMEA backlog, per our off line conversation. Thank you !

Comment by Kaloian Manassiev [ 03/Jul/23 ]

Can we please get rid of the `ns()` method on the RecordStore rather than doubling down on it? RecordStores, in their lifetime can belong to differently-named collections with the same UUID, so it is not very meaningful to expose the `ns()` first class. If anything, for the purposes of logging we should just use the same resolution we do for the ResourceIds.

Generated at Thu Feb 08 06:38:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.