janl opened a new issue, #5685: URL: https://github.com/apache/couchdb/issues/5685
#5655 introduced a new [database API endpoint](https://github.com/apache/couchdb/pull/5655/files#diff-82d8b792ffdb5c58dcd7d9c3bb2b4582e46d03e416f62104a403242f42e2a234R38): `/{db}/_auto_purge` which is a `/{db}/_security`-like JSON structure with a single key `deleted_document_ttl`. With [other features on the horizon](https://github.com/apache/couchdb/pull/5583/files#top) that need per-db configuration, I suggest we formalise an extensible API for database config modelled after the server _config API and move the `_auto_purge` functionality into that. In addition, this allows us to consolidate a few other things like `_revs_limit` and `_purged_infos_limit` into that API as well. The general idea is to model the behaviour on how `/_config` works. I’ll skip the `/_node/{name-or_local}` prefix for brevity. To recap how `/_config` works: - `GET /_config` -> returns all config in a JSON object, top level keys are config sections, second level keys are config settings and their values are the config value. - `GET `/_config/section` -> returns a JSON response of all config keys and their values for a particular section. - `GET /_config/section/key` -> returns just the config value for a given section and key. - `PUT /_config/section/key value` -> updates the value of section/key to the provided value and returns the old value. - `DELETE /_config/section/key` -> removes a configuration option, this means the source-default is assumed. I propose `/db/_config` to behave exactly the same: - `GET /{db}/_config` -> returns all config in a JSON object, top level keys are config sections, second level keys are config settings and their values are the config value. - `GET `/{db}/_config/section` -> returns a JSON response of all config keys and their values for a particular section. - `GET /{db}/_config/section/key` -> returns just the config value for a given section and key. - `PUT /{db}/_config/section/key value` -> updates the value of section/key to the provided value and returns the old value. - `DELETE /{db}/_config/section/key` -> removes a configuration option, this means the source-default is assumed. TBD: behaviour as we do not want to actually remove the key entry, just reset its value To get started, we should implement the following sections and config options: - `section` `key` `default value` - `revs` `limit` `1000` - `purges` `limit` `1000` - `auto_purge` `deleted_document_ttl` `TBD` // also TBD about the unit, which is currently seconds and a bit unwieldy. We want to suggest long timeframes, so maybe days or months? - `compaction` `generations` `0` (for #5583 when it lands) Optional: Bob suggested to move the `_security` object here as well, which I don’t object to, but it does not fit the data structure without some awkwardness about the value being a JSON structure where everything else is a scalar. I’m open to other suggestions, but it’d be awkward to invent something that does not behave like server `_changes` already. - `security` `admins` `{names: [], roles: ["_admin"]}` - `security` `members` `{names: [], roles: ["_admin"]}` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
