[SERVER-69585] Get rid of the UUID from the database version Created: 12/Sep/22  Updated: 18/Jan/24

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Antonio Fuschetto Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: oldshardingemea, shardingemea-qw
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-84758 Remove UUID in DatabaseVersion Closed
Gantt Dependency
has to be done after SERVER-71052 Remove database metadata by querying ... Closed
Assigned Teams:
Catalog and Routing
Participants:
Story Points: 2

 Description   

The UUID field of the database version structure has been logically replaced by the timestamp starting from version 4.9 (see SERVER-52933).

From version 5.2, this field has no reason to exist so it can be removed for clarity.



 Comments   
Comment by Antonio Fuschetto [ 03/Nov/22 ]

There is a backward-compatibility problem, highlighted by the multi-version test suites, that forces us to postpone this change. The problematic case can be summarized with an example:

  • Using new binary version (that onboards this change), the database TestDB is create and its metadata contains the timestamp (not the UUID).
  • The cluster is downgraded (so, the binaries don't onboard the changes), the database TestDB is dropped, but the operation fails because the filter to get its metadata uses the UUID (that is unavailable).

The proposal is to change the filter used to remove the database metadata using the timestamp in the next version (i.e., 7.0) and actually remove the UUID in the following version (i.e., 7.1/8.0).

All the required changes are already here.

Comment by Antonio Fuschetto [ 28/Oct/22 ]

Assigning back to me as internally discussed. I will include pol.pinol@mongodb.com in the development process.

Comment by Antonio Fuschetto [ 28/Oct/22 ]

A few weeks ago, I moved back this ticket to the backlog because it requires a little more of investigation. In other words, it's not probably a quick win as I initially assumed.

Indeed, to remove the database metadata from the config database, the UUID is currently used as part of the query to ensure the idempotence of the operation. Probably, this can be safely changed by using the database timestamp to query the same data.

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