Keith Bostic Is there some way for the user to know the names we assign to different configuration values. i.e: you are keying the search based on config_entries, the strings in there seem OK to me, but aren't necessarily consistent. For example there are four wiredtiger_open configurations - are there ever cases where a user would want wiredtiger_open_usercfg? Further most of the keys have reasonably logical names e.g: session.create, but some less so, e.g: table.meta. Even the logical names use shortened versions of handle names - if we are going to expose those I think they should match exactly the name in the API - for example WT_SESSION.

I'd be more inclined to define a set of options for the configuration validation. That saves us exposing the internal strings we are using as keys - so we have flexibility to change them in the future. Defining a set of supported names should allow us to expose this in a way that documents itself as well.

@agorrod, I use a stripped-down handle name plus the method names because that's what we did in the WT_CONNECTION.configure_method API, which has the same naming problem and which we solved this way.

I like your idea of using the full cookie and method (for example, WT_SESSION.create) better than what we're doing now; if we switch to that approach, we should convert the WT_CONNECTION.configure_method API as well.

Alternatively, I agree it's not documented anywhere we use stripped-down handle names plus the method names, I can add that documentation.

Users won't change anything other than the configurations associated with our published methods, I can't think of a scenario where a user changing the configuration of table.meta would make sense. We document the argument is "the name of a method", which isn't great documentation, but excludes things like table.meta. We're not exposing any internal naming scheme here, it's simply our internal naming matches method names so we skipped the extra lookup.

I don't understand what you mean by "a set of options for the configuration validation", but using the full handle name and method would mean we no longer expose any internal naming.

@agorrod, @michaelcahill, I've updated wiredtiger_config_validate() and WT_CONNECTION.configure_method() to use the names Alex suggested.

I believe the only remaining question is if we should add a WT_EVENT_HANDLER argument to the wiredtiger_config_validate() API to handle error messages?

Additional ticket information from GitHub

Commits in this ticket:

• d2f6ef9c460853dfd79cf436bc8bb5b626c0fd15
• 87d281673eb9eae54de9d536732aadf83dae6b2d
• 1c6da94a516bb3a24990e73d03cd15ce91a6b2e5
• ff9c14539f4d68c6671e4463508997740c07437a
• c4fd5d8eb50897e10116a77a10a0ed180202c94e
• f75adfa400cfe49abbb8d7d066986fae71b99dbd
• 38f5d35e0d23323f79c67e167388e962cb159016
• dd45a717c8770d6287dd39faca40028edf4d523d
• 08d92c3ed73ffa76ebb26f799b962f87e235329a
• 97612b65e0c395d867c24ac476442fbdf6ff44b6
• fa2dd207a9ba94bb0ada7dc2749145f8f1413ab9

This ticket was referenced in the following commits:

• 3e384a74e6e02793e983a232a7bb64d6d358eeff

I believe this ticket can be resolved/closed with the merge of the WiredTiger branch in GitHub issue 1739.