Problem
Sharded collections in the tree view don't display their shard key anywhere visible. Users must use external tools (Azure Portal, shell) to check which field(s) a collection is sharded on. This information is important for understanding query performance and data distribution.
The raw MongoDB listCollections() response includes an options field that can contain shard key information, but the current CollectionItemModel interface only preserves name and type, discarding this data.
Expected Behavior
When a collection has a shard key, it should be displayed in the collection's tooltip:
### my-collection
`Collection`
---
**Database:** my-database
**Documents:** 5.2k
**Shard Key:** { userId: "hashed" }
Development Hints
Since this is a good first issue, here are some hints on where to start:
Step 1: Extend the model in src/documentdb/ClustersClient.ts
The CollectionItemModel interface currently only captures name and type:
export interface CollectionItemModel {
name: string;
type?: string;
}
Add an optional options field (or specifically a shardKey field) to preserve the shard key from the MongoDB response. The raw listCollections() response already contains this data, but it gets discarded during the type assignment:
const rawCollections = await this._mongoClient.db(databaseName).listCollections().toArray();
const collections: CollectionItemModel[] = rawCollections; // options field is lost here
Step 2: Update the tooltip in src/tree/documentdb/CollectionItem.ts
In buildTooltip(), add a section for the shard key when it exists. Format the key object as a readable string (e.g., { userId: "hashed" } or { region: 1, date: 1 }).
Notes:
- Not all collections are sharded. The shard key section should only appear when the data is present.
- The shard key is a key-value object where values indicate the sharding strategy (e.g.,
1 for range, "hashed" for hash-based).
- The
listCollections() response format may vary. Test with both sharded and non-sharded collections.
- Some DocumentDB configurations may not return shard key info at all. Handle missing data gracefully.
Files to Modify
| File |
Change |
src/documentdb/ClustersClient.ts |
Extend CollectionItemModel to include shard key data |
src/tree/documentdb/CollectionItem.ts |
Add shard key section to buildTooltip() |
Acceptance Criteria
Problem
Sharded collections in the tree view don't display their shard key anywhere visible. Users must use external tools (Azure Portal, shell) to check which field(s) a collection is sharded on. This information is important for understanding query performance and data distribution.
The raw MongoDB
listCollections()response includes anoptionsfield that can contain shard key information, but the currentCollectionItemModelinterface only preservesnameandtype, discarding this data.Expected Behavior
When a collection has a shard key, it should be displayed in the collection's tooltip:
Development Hints
Since this is a
good first issue, here are some hints on where to start:Step 1: Extend the model in
src/documentdb/ClustersClient.tsThe
CollectionItemModelinterface currently only capturesnameandtype:Add an optional
optionsfield (or specifically ashardKeyfield) to preserve the shard key from the MongoDB response. The rawlistCollections()response already contains this data, but it gets discarded during the type assignment:Step 2: Update the tooltip in
src/tree/documentdb/CollectionItem.tsIn
buildTooltip(), add a section for the shard key when it exists. Format the key object as a readable string (e.g.,{ userId: "hashed" }or{ region: 1, date: 1 }).Notes:
1for range,"hashed"for hash-based).listCollections()response format may vary. Test with both sharded and non-sharded collections.Files to Modify
src/documentdb/ClustersClient.tsCollectionItemModelto include shard key datasrc/tree/documentdb/CollectionItem.tsbuildTooltip()Acceptance Criteria
CollectionItemModelpreserves shard key data from thelistCollections()response{ field: 1 }or{ field: "hashed" })