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
For a production launch we'll need an equivalent to #1545 for configuration values. Rather than relying on an external service we should build this into FTL itself. The table will be relatively straightforward, something like this:
CREATETABLEmodule_configuration (
id BIGINTNOT NULL GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
created_at TIMESTAMPTZNOT NULL DEFAULT (NOW() AT TIME ZONE 'utc'),
module TEXT, -- If NULL, configuration is global.
name TEXTNOT NULL,
value JSONB NOT NULL
)
The text was updated successfully, but these errors were encountered:
…1570)
Fixes#1548
This doesn't hook anything up yet - just adds the provider and resolver
that we'll use in prod
Changes:
* Adds `DBConfig[Resolver|Provider]` to the `configuration` package,
where the resolver does very little, and the provider executes most of
the actual database SQL queries. For DB-backed configs, all the data
needed to retrieve a config can be found in the `ref` without a separate
key, so the URLs are all simple `db://` stubs that exist only to satisfy
the existing provider and resolver interfaces, which expect URLs to be
passed as keys.
* Refactors the 3 Err types, `isNotFound`, and `translatePGError` out of
the `dal` package into a separate `dalerrors`
* Adds a public getter for the `db` field in `dal.DAL` so that we can
connect to the same DB in the database config resolver/provider
For a production launch we'll need an equivalent to #1545 for configuration values. Rather than relying on an external service we should build this into FTL itself. The table will be relatively straightforward, something like this:
The text was updated successfully, but these errors were encountered: