Skip to content
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

Implement a database-backed config resolver + provider for production #1548

Closed
alecthomas opened this issue May 21, 2024 · 0 comments · Fixed by #1570
Closed

Implement a database-backed config resolver + provider for production #1548

alecthomas opened this issue May 21, 2024 · 0 comments · Fixed by #1570
Assignees

Comments

@alecthomas
Copy link
Collaborator

alecthomas commented May 21, 2024

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:

CREATE TABLE module_configuration (
  id BIGINT NOT NULL GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  created_at TIMESTAMPTZ NOT NULL DEFAULT (NOW() AT TIME ZONE 'utc'),
  module TEXT, -- If NULL, configuration is global.
  name TEXT NOT NULL,
  value JSONB NOT NULL
)
@github-actions github-actions bot added the triage Issue needs triaging label May 21, 2024
@ftl-robot ftl-robot mentioned this issue May 21, 2024
@github-actions github-actions bot removed the triage Issue needs triaging label May 21, 2024
deniseli added a commit that referenced this issue May 29, 2024
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants