In this page we will see how to get runtime type safety for configs with dynamic schema.
Our top level config contains a single field -
db, with the type
Based on user choice, we would like its type to be either
PostGreSQLConfig at runtime.
The two schemas differs: config files that are appropriate for one are inappropriate for the other.
For each of the two schemas, we have two options - one for prod and one for staging:
When composing the config, we need to select both the schema and the actual config group option. This is what the defaults list looks like:
Let's dissect the how we store the schemas into the
There are several notable things here:
- We use the group
Config Groups are mutually exclusive, only one option can be selected from a Config Group. We want to select both the schema and the config. Storing all schemas in subgroups of the config group schema is good practice. This also helps in preventing name collisions.
- We need to specify the package to be
db. By default, the package for configs stored in the
_group_. We want to schematize
schema.dbin the config so we have to override that.
By default, we get the mysql staging config:
We can change both the schema and the config:
If we try to use a postgresql config without changing the schema as well we will get an error: