Config loaded from DB

[pwoznicki]

Looking at the load_dash_conf, it loads the dashboard configuration from the swag DB, unless it's default, in which case it loads it from config.yaml. I have a few questions/ideas to improve that:

1. dashboard config could be further split, e.g. into dashboard, window, report, and annotation to separate user settings (dashboard) and annotation/report rendering schemas. That would give us finer control over updates, loading etc.
2. What's the benefit of storing the config in the DB over storing it in JSON? It brings additional latency & management overhead, is not version controlled, and is a bit confusing as the default is loaded from JSON (it looks to me like we just want to cache user settings). Is JSON not enough for us?
3. Detail - do we need to store page_title in the config? are we planning to have multiple titles? :)

[laqua-stack]

dashboard config could be further split, e.g. into dashboard, window, report, and annotation to separate user settings (dashboard) and annotation/report rendering schemas. That would give us finer control over updates, loading etc.

That is a good point and is definetly on our plate. We would need to change the code at several places, when the st.session_state.dash_conf is adressed

What's the benefit of storing the config in the DB over storing it in JSON? It brings additional latency & management overhead, is not version controlled, and is a bit confusing as the default is loaded from JSON (it looks to me like we just want to cache user settings). Is JSON not enough for us?

The latency is minor, since it only loaded once in the start. Especially compared to loading images from the DB. The benefit is, that we can store (actually, including a timestamp and names) user configs. Currently I consider the most relevant stored parameter the last case_no. But in principle also windowing presets (we think of extending the possibilities here) as well. The default is only loading from json, if nothing is in the Database. By default it loads the latest config.

Detail - do we need to store page_title in the config? are we planning to have multiple titles? :)

Maybe ;-) We speculated on using the annotation framework for multiple tasks as well.. For the most straight-forward use consider e.g. MIMIC vs. UKW data...

[pwoznicki]

The latency is minor, since it only loaded once in the start. Especially compared to loading images from the DB. The benefit is, that we can store (actually, including a timestamp and names) user configs. Currently I consider the most relevant stored parameter the last case_no. But in principle also windowing presets (we think of extending the possibilities here) as well.

That's fine, but unless we really separate out custom user settings from logic settings, the setup may cause some unexpected bugs later on. Other than that, user config in the db sounds good.

Maybe ;-) We speculated on using the annotation framework for multiple tasks as well.. For the most straight-forward use consider e.g. MIMIC vs. UKW data...

Right, makes sense :)