I really hate our UserSetting database model. Yuck it sucks. Also we have a whole bunch of static configs in both globals.ts and just spread throughout the app.

Things like:

• Tabulator page size
• Default table column width behavior
• Selected theme
• client or native menu styles
• etc etc

These are UNREASONBLY difficult to change right now and the database is a terrible place to change them.

What if we made it more like a Video game and used an ini file?

I think this would be a great way to make Beekeeper Studio more customizable.

Open questions / problems

• How do we have an easy to edit configuration file in development?
  • In development it should look for a local.config.ini in the current working directory to let us override configs
  • In development we should watch default.config.ini and local.config.ini and auto-reload config values when they change.
• How do we provide default values? Is that in the code somewhere?
  • We should bundle a default.config.ini, this contains all the default values.
  • Users get to edit a $CONFIG_DIR/user.config.ini
• Can we type our configuration to make it easy to work with in development?
  • We can if we want to for some specific configs. I don't think we should though.
• What happens when a user edits their ini file and the next version of Beekeeper Studio adds new configuration keys or changes defaults? (This is easy in the current system)
  • Changes are made to default.config.ini
  • Users can add any new configs they like to user.config.ini
  • We should add a warning for unrecognized config keys

Ini config system design

• Use the ini package
• Be sure to use safe when serializing values in the file - https://www.npmjs.com/package/ini#safeval
• We should allow users to provide config values as environment variables with a prefix: beekeeper_{configkey}
• We should log.debug all loaded configs when starting the app. That way we can debug in production.
• Add a pre-commit git hook that generates a .d.ts file for the config object based on the default config (if the default config file has changed)
• Settings should be available globally on a BkConfig object, and as a vue plugin, for usage within vue components
  • This does not need to be a reactive object initially, or in the store.
  • This object should load each config file, and keep track of where config values come from -- this will help debugging.
  • BkConfig.key should work, and just return the value, eg BkConfig.tableTable.pageSize // returns 100
  • Configs can be loaded using ini, and merged using lodash _merge - eg const result = _.merge({ }, defaults, user, local, env);
  • BkConfig.debug(key) should return an object with the key, which file was used to provide the value, and all the values present in other sources. eg { key: "abc", value: "foo", valueSource: "user", otherValues: { user: "foo", default: "bar", env: undefined local: undefined }}
  • BkConfig.debugAll should return an array of debug values
  • BkConfig.has(key) should return a true/false, using _.isNil, can accept dot notation (tableTable.pageSize)
  • BkConfig.get(key) should work, and also accept dot notation - BkConfig.get('tableTable.pageSize')

What configs should we move to the ini file system for v1?

• All items from globals.ts
• Any Magic numbers or magic values sprinkled throughout the codebase should be moved.
• As many keybindings as possible - these should all be in their own section. This might be really hard to do fully as some keybindings are handled by tabulator or CodeMirror.

Config file organization

We can use sections for the different tabs. We should have the following sections:

• No top level keys
• db for general settings related to drivers, ui for general UI settings. Eg defualt DB timeouts, and maybe stylesheets for the UI.
• keybindings for keybindings. The key format here should follow the same naming convention as the ui section. Global keybindings (copy, paste) should go as root, tab-specific keybindings should be prefixed with the ui component or tab, eg queryEditor.action
• ui.<tabname> for settings related to that tab. Make it the same name as the component, so ui.tableTable and ui.queryEditor
  • eg: ui.tableTable.pageSize, or ui.queryEditor.editMode
• db.<drivername> for settings related to the drivers - eg db.postgres.timeOut

Example file

[keybindings]
quickSearch = CmdOrCtrl+p
copy = CmdOrCtrl+c
queryEditor.runAlternate = CmdOrCtrl+enter


[ui]
theme = dark

[ui.tableTable]
pageSize = 100

[ui.queryEditor]
maxResults = 50000

[db]
connectTimeout = 3600
sshTimeout = 3600

[db.postgres]
connectTimeout = 3100

[db.mysql]
; etc etc