-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
refactor: decouple config names and values #4157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: decouple config names and values #4157
Conversation
I think we do need a SSoT for the config names, but the refactor is not looking like a gain in maintenance (has more LOCs).
@taimoorzaeem As a shorter step towards #4154, how about first solving the duplication problem for the sample config in the CLI?
postgrest/src/PostgREST/CLI.hs
Lines 126 to 238 in c1eb8af
Then the benefit of the refactor will be clear.
postgrest/src/PostgREST/CLI.hs
Lines 143 to 151 in f295130
The description before each config is understandable but can we afford to lose this trailing ##
and #
just before in each config here for instance, in db-pre-config
and db-max-rows
? Not sure what the means TBH.
My idea is to utilize Config.toText
and intercalate with the description list. Just these trailing ##
and #
get in the way.
IIRC # db-max-rows = 1000
has the #
because it's actually not set, there's no default. The configs that don't have a #
prefix have a default like db-schemas = "public"
.
So the above means that there's an additional field for a type (that has possible values: default or empty), that would translate to those commented out configs.
I guess we put ##
in the description for some tools (like vim) that automatically un-comment by removing one #
, so the config remains valid.
It would be just a nicety to keep them as is.
IIRC # db-max-rows = 1000 has the # because it's actually not set, there's no default.
Agree, these are the ones labeled as "Default: n/a" in the docs (or in the case above when: default = not set). Note that this doesn't seem to be consistent right now, cause there are configs that are commented when they have a default value (like the db-pool...
examples), so they shouldn't be commented anymore. I think these are specified as Maybe
types in the AppConfig
, so that could be a way to detect them programmatically.
@taimoorzaeem As a shorter step towards #4154, how about first solving the duplication problem for the sample config in the CLI?
postgrest/src/PostgREST/CLI.hs
Lines 126 to 128 in c1eb8af
exampleConfigFile :: [Char]exampleConfigFile =[str|## Admin server used for checks. It's disabled by default unless a port is specified.Then the benefit of the refactor will be clear.
One way to solve this could be to do something like:
{-# OPTIONS_GHC -Wunused-record-wildcards #-} -- only available in ghc >= 9.6.1 exampleConfig :: AppConfig ... toExampleFile :: AppConfig -> [Char] toExampleFile AppConfig{..} =
Now, we want to haskell to complain at compile time if some field is not consumed in the toExampleFile
function, so for that we can use -Wunused-record-wildcards
. But, this warning is only available in GHC >= 9.6.1
according to haskell errors, so I think we need wait for the upgrade for that.
Uh oh!
There was an error while loading. Please reload this page.
Decouples the config names and values in config dumping. This opens up space for easier implementation of #4154. Not sure if that is the best way to refactor this. Would love any suggestions.