32 lines
1.4 KiB
ReStructuredText
32 lines
1.4 KiB
ReStructuredText
|
|
||
|
|
Overview
|
||
|
|
========
|
||
|
|
|
||
|
|
The basic idea of course is that the app needs to be configurable, so the
|
||
|
|
question is how to go about that.
|
||
|
|
|
||
|
|
The short answer is, "We always use config files but can also store config in
|
||
|
|
the database where applicable."
|
||
|
|
|
||
|
|
The advantage to config files is that they are easier to get started with, but
|
||
|
|
also we can restrict access at the file system level, which means we can (more
|
||
|
|
safely) store sensitive information in them.
|
||
|
|
|
||
|
|
The advantage to storing config in DB, is that one can change config on-the-fly
|
||
|
|
using e.g. the web app. (Whereas changing a config file requires the app to be
|
||
|
|
restarted, so it will read the new file contents.)
|
||
|
|
|
||
|
|
Generally speaking, certain config which is needed during app startup (e.g. DB
|
||
|
|
access credentials and logging config), or which is deemed "sensitive"
|
||
|
|
(passwords, API keys etc.), is kept in config files, and the remainder is kept
|
||
|
|
in the DB (if there is one).
|
||
|
|
|
||
|
|
This behavior is itself configurable, but most typically, the app will not care
|
||
|
|
where a given setting is defined (file vs. DB) but if one is defined in both
|
||
|
|
places the DB value would win. But the app can request a config value from
|
||
|
|
"file only" and ignore the DB, where that is desirable (e.g. when reading
|
||
|
|
settings required for startup).
|
||
|
|
|
||
|
|
We are still in the Base Layer docs at this point, so we'll focus on the config
|
||
|
|
files first, and come back to the DB near the end.
|