You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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?
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
I really want Beekeeper Studio to be really easy and fun to mod. Like games are fun and easy to mod. Especially like how earlier games like Doom were easy to mod, or modern games like Skyrim or Half Life.
It should be easy and fun to make Beekeeper Studio 'yours'.
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:
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
$CONFIG_DIR/user.config.ini
can
if we want to for some specific configs. I don't think we should though.ini
file and the next version of Beekeeper Studio adds new configuration keys or changes defaults? (This is easy in the current system)Ini config system design
safe
when serializing values in the file - https://www.npmjs.com/package/ini#safevalbeekeeper_{configkey}
log.debug
all loaded configs when starting the app. That way we can debug in production..d.ts
file for the config object based on the default config (if the default config file has changed)BkConfig
object, and as a vue plugin, for usage within vue componentsBkConfig.key
should work, and just return the value, egBkConfig.tableTable.pageSize // returns 100
_merge
- egconst 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 valuesBkConfig.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?
globals.ts
Config file organization
We can use sections for the different tabs. We should have the following sections:
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, egqueryEditor.action
ui.<tabname>
for settings related to that tab. Make it the same name as the component, soui.tableTable
andui.queryEditor
ui.tableTable.pageSize
, orui.queryEditor.editMode
db.<drivername>
for settings related to the drivers - egdb.postgres.timeOut
Example file
The text was updated successfully, but these errors were encountered: