[DOCS-12682] create command option `indexOptionsDefaults` duplicates storageEngine documentation Created: 06/May/19 Updated: 30/Oct/23 Resolved: 13/Mar/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | Server |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Samuel Rossi (Inactive) | Assignee: | Kay Kim (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 47 weeks, 2 days ago |
| Description |
DescriptionOn the documentation page for the create command, the description of indexOptionsDefaults seems to be copied from the description of the storageEngine option, which seems a little strange, as I'd expect that indexOptionsDefaults would take in a document that looks like the options passed to createIndexes. Is this a mistake, or am I misunderstanding the purpose of the field? Scope of changesImpact to Other DocsMVP (Work and Date)Resources (Scope or Design Docs, Invision, etc.) |
| Comments |
| Comment by Ashley Brown [ 13/Mar/23 ] |
|
Hi, we're closing this ticket because we believe the discussion in comments means we shouldn't take any action here. If you believe this is an error, please reopen the ticket with a comment explaining why and we'll take a look. Thanks! |
| Comment by Samuel Rossi (Inactive) [ 07/May/19 ] |
|
For the create collection helper, yes, we allow indexOptionDefaults, but it seems weird to expose this if we can't actually document the format of the documents that are used there. In our index management spec, we also currently require that drivers expose a storageEngine option, but again, it seems weird to require this if users aren't supposed to know what to populate it with. One thing that might not be clear here is that in statically-typed languages, we define structs for each of the options types rather than accepting an arbitrary document. For example, a driver would define an IndexOptions struct which has a field called storageEngine. I'm thinking that it might not make sense for our spec to require that drivers have a storageEngine field if we can't even document what form it should take. For dynamically typed languages that just take a dictionary of options, this isn't as big of a deal (since they can just allow the user to specify arbitrary keys in the options and let the server validate them), but it seems counterintuitive that we'd go out of our way to add the ability to specify a storageEngine option if we can't actually document how to use it. |
| Comment by Max Hirschhorn [ 07/May/19 ] |
My impression was for drivers that offer a create_collection() helper, they'd allow the indexOptionDefaults option to be specified. Drivers shouldn't document anything about WiredTiger configString. |
| Comment by Samuel Rossi (Inactive) [ 07/May/19 ] |
|
Interesting! The drivers specification for index management requires that drivers allow users to specify a storageEngine option, and I was having trouble finding the documentation for this, so the fact that it's purposely not documented would explain that. Is this something that we shouldn't be exposing to users? The drivers all have runCommand helpers, so it would still be possible for users who know the proper semantics of a config string to express it. manually. |
| Comment by Ravind Kumar (Inactive) [ 06/May/19 ] |
|
Looking at the source ticket |