Github user kxepal commented on a diff in the pull request:
https://github.com/apache/couchdb/pull/309#discussion_r26230606
--- Diff: rel/overlay/etc/default.ini ---
@@ -23,6 +23,7 @@ file_compression = snappy
; and/or more OS page cache hits, but they can also increase overall
response
; time for writes when there are many attachment write requests in
parallel.
attachment_stream_buffer_size = 4096
+db_definitions = [couch_dbs, mem3_dbs, couch_replicator_dbs, cassim_dbs]
--- End diff --
Can we not have this list in config at all?
Here is the problem: you're going to install couch_foo plugin which has
`couch_define_db` behaviour. Plugin install happens in one-single-click way, so
user don't have to touch any configs for that. But now, to let this plugin
works it need to add himself to that list. That literally means: config:get =>
put itself these or ensure that it's defined once and only => serialize list =>
config:set...mmm, ok. Now we want to uninstall that plugin...
You got the idea? Having `couch_define_db` behaviour isn't enough to let
your (abstract) app work correctly: you have to modify this config value. So,
technically, we still have a SYSTEM_DATABASES list, not in Erlang code, but in
ini file. We cannot define own system databases with it, but enforces to keep
this list in actual state for all our apps we have.
P.S. Few edge cases:
- In default.ini we have `[couch_dbs, mem3_dbs, couch_replicator_dbs,
cassim_dbs]`
- User install a couch_foo plugin which puts a new value in local.ini
`[couch_dbs, mem3_dbs, couch_replicator_dbs, cassim_dbs, couch_foo]`
- In new CouchDB release we add new app which also defines own system
database, so default.ini changed in the way to have `[couch_dbs, mem3_dbs,
couch_replicator_dbs, cassim_dbs, couch_new_app]`
Question: how we'll deal with upgrade, since values in local.ini overrides
default.ini?
What if I have a non existed module in this list from the plugin I just
removed?
What if I have it defined here twice or more?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
