[GODRIVER-964] make option type construction consistent with the options package (e.g. readpref, readconcern, writeconcern) Created: 15/Apr/19  Updated: 19/Dec/22  Resolved: 19/Dec/22

Status: Closed
Project: Go Driver
Component/s: Options & Configuration
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Sam Kleinman (Inactive) Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GODRIVER-2034 API Consistency for read/write Closed
Related
related to GODRIVER-2689 Simplify the "readpref" API Backlog
related to GODRIVER-2685 Simplify "writeconcern" API Closed
related to GODRIVER-2686 Simplify "readconcern" API Closed

 Description   

Revised:

The mongo/options package uses chained-setters for constructing options. But types referenced by mongo/options, such as WriteConcern, ReadConcern, etc., are constructed with functional options style. Mixing styles confuses users and could be revised/replaced for consistency.

Additionally, some types are defined within mongo/options (such as Credential, Collation, etc.) but others have their own package (e.g. readpref.ReadPref, etc.). There is no obvious guide for what to expect to find where.

Original:

specifying writeconcern is difficult and confusing, and doesn't conform with the idiom established for options in the driver. It should be specifiable, perhaps with its own options type.



 Comments   
Comment by Matt Dale [ 12/Dec/22 ]

I've created tickets that describe proposed simplifications to the writeconcern, readconcern, and readpref APIs (GODRIVER-2685, GODRIVER-2686, GODRIVER-2689, respectively) that are currently part of the Go Driver 2.0 scope. Those tickets propose removing the "functional options" pattern completely in favor of just exporting all fields in the respective configuration structs. It doesn't recommend adding the "chainable setters" pattern because that seems redundant. If we determine that the "chainable setters" pattern is useful or required, we can add it in a later 2.x release.

Concerning moving those packages to the options package, it seems likely we'd run into some namespace collisions. It's not clear that the obviousness and discoverability improvements would outweigh the possibly awkward naming plus the added 1.x->2.0 migration pain. I recommend against merging these packages into the options package.

Edit: Moving to "Needs Triage" with the recommendation that we close this as "Won't Fix".

P.S. I think we should remove the "chainable setters" pattern from the options package (maybe retaining un-chainable setters in a few cases) in favor of just setting struct fields. However, not many people have complained about the usability of the "chainable setters" pattern, so it's not clear if removing it in Go Driver 2.0 would be worth the added migration pain. The motivation is mostly from the Go Driver team because maintaining all of those setters can be a lot of work.

Comment by Sam Kleinman (Inactive) [ 16/Apr/19 ]

I changed the title of the ticket.

Discoverability and documentation were definitely a struggle.

I'm not sure there is a convention to get used to given the fact that there are multiple paradigms. It also renders the chainability less useful, because you have to construct the objects without chaining.

Generated at Thu Feb 08 08:35:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.