[SERVER-85123] Define a vision for the future of the catalog w/ explanation of benefits Created: 10/Jan/18  Updated: 13/Jan/24  Resolved: 04/Jun/18

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

Type: Task Priority: Major - P3
Reporter: Ian Whalen (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Sprint: Storage NYC 2018-06-18
Participants:

 Comments   
Comment by Ian Whalen (Inactive) [ 04/Jun/18 ]

Rather than defining and running any big project about the catalog, we instead plan to incrementally improve it over the course of the next few years worth of Storage projects.

Comment by Ian Whalen (Inactive) [ 30/Mar/18 ]

It was intended to end up as a wiki page, I assume? I don't think we have a standard way of handling those - happy to use tasks or Server Documents. but either way, clearing the fixVersion is fine.

Comment by Gregory McKeon (Inactive) [ 30/Mar/18 ]

ian.whalen should this be a server document? Also cleared the fixversion - is that ok?

Comment by Daniel Gottlieb (Inactive) [ 02/Feb/18 ]
  1. Rebuilding indexes requires the collection object. From conversations I've had, given a record and an index specification, generating the index key also* requires the catalog.
  2. The lifetime relationships between MongoDB catalog objects (e.g: Database, Collection) and storage engine catalog objects (e.g: DatabaseCatalogEntry) are not well defined. For example, closing a database deletes the Database object, but not the KVStorageEngine's implementation, KVDatabaseCatalogEntry.
Comment by Ian Whalen (Inactive) [ 10/Jan/18 ]

In particular this should also document places in which the lack of a vision/time spent on improving has slowed the progress of other work.

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