Read configuration options from design spec json #282
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces the approach to read configuration options (such as values in dropdowns and which options to enable) based on an embedded design json vs. reading for the existence of tables or querying large result tables.
Following elements are updated:
Notes
The original code remains in place if the design json isn't specified. To make it simpler, a new option was defined
shinyApp.designSpec
that can be used to contain the json-parsed design spec. SeeOhdsiShinyModules::getExampleAnalysisSpec()
for an implementation, and note in app.R the following:With this change, you can run the example application where it will read the configuration from the JSON.
Which modules are impacted?
For some modules, there may be reference tables created that are suited to performing a lookup on in order to get the options for the given study and don't need to change for this PR. But some cases (such as characterization-incidence and possibly cohort diagnostics), you need to resort to querying the results to figure out what you selected in an analysis. This could lead to long load times and inefficient use of resources (such as seeking a billion records to find out there are two genders available).
Incidence Notes:
While I calculate the age group names from the analysis specification, I can't do the same for years and gender. It is not efficient to query a potential billion record table to find 10 distinct years or 2 distinct genders, so this PR hard codes the selections for those options to be 'Any, MALE, FEMALE' for gender and the sequence 2010 - 2024 for years. We can make this a global option to use across the shiny modules in the event we determine that we can live with a subset of choices instead of deriving them from results.