Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-1739

Add an API to validate configuration strings.

    Details

    • Type: Task
    • Status: Resolved
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT2.6.0
    • Labels:

      Description

      @michaelcahill, the MongoDB team asked for a way to validate configuration strings – here's one approach for your consideration.

      I was torn between adding a WT_CONNECTION method, and another global, but eventually decided on the latter.

        Issue Links

          Activity

          Hide
          agorrod Alex Gorrod added a comment - - edited

          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.

          Show
          agorrod Alex Gorrod added a comment - - edited 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.
          Hide
          keith.bostic Keith Bostic added a comment -

          @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.

          Show
          keith.bostic Keith Bostic added a comment - @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.
          Hide
          keith.bostic Keith Bostic added a comment -

          @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?

          Show
          keith.bostic Keith Bostic added a comment - @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?
          Show
          ramon.fernandez Ramon Fernandez added a comment - 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
          Hide
          keith.bostic Keith Bostic added a comment -

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

          Show
          keith.bostic Keith Bostic added a comment - I believe this ticket can be resolved/closed with the merge of the WiredTiger branch in GitHub issue 1739 .

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since reply:
                1 year, 47 weeks, 6 days ago
                Date of 1st Reply: