[CXX-1351] Investigate implementing the index view API described in the index management spec Created: 30/May/17  Updated: 31/Mar/22

Status: Backlog
Project: C++ Driver
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Samuel Rossi (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to CXX-1272 Audit driver against Index Management... Closed

 Description   

The index management spec details two APIs, the "standard API" and the "index view API" and gives drivers the option of implementing either. mongocxx currently implements all of the standard API except the `create_indexes`, `drop_index`, and `drop_indexes` methods. We should decide whether we want to implement the index view spec and deprecate the collection methods pertaining to indexes or simply finish implementing the standard API.



 Comments   
Comment by David Golden [ 30/May/17 ]

I agree that we should finish the "standard API".

I wonder if it might make sense to implement an indexModel that takes a BSON document for options so that we're forward compatible instead of changing the index::options class every time the server adds an indexing feature. Or PIMPL index::options as another way of doing a similar thing.

Comment by Samuel Rossi (Inactive) [ 30/May/17 ]

Given that we already have `create_index` and `list_indexes` as methods on collection and that the spec gives no preference to either of the API choices, I think that it would be better for us to implement the remainder of the standard API rather than to switch to the index view API. Having the aforementioned methods present in addition to the index view API seems like it could confuse users (who might wonder why we have collection::create_index but not collection::drop_index), and I don't think that switching to the index view API is a big enough win to be worth deleting the methods and breaking compatibility. One alternative might be to fully implement both APIs, but I don't think that duplicating the functionality across two APIs is as clean as just using the standard API, which users of the driver will already be partially familiar with and using.

Generated at Wed Feb 07 22:02:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.