-
Notifications
You must be signed in to change notification settings - Fork 5
Open
Description
Summary
Investigate replacing the current single JSON file configuration storage with a persistent storage backend such as SQLite or Redis.
The goal is to improve concurrency, reliability, and scalability, and to produce an ADR documenting the decision.
Use Case
Currently, configuration is stored in a single JSON file on disk. This approach has several limitations:
- No transactional guarantees; concurrent writes risk data loss.
- Updates require rewriting the entire file.
- Difficult to support advanced features like config history, partial updates, or live reloads.
By using a persistent storage backend, we could enable:
- Atomic updates and transactions.
- Concurrent safe reads/writes.
- Enable advanced scenarios.
Proposed Solution
- Investigate SQLite as a local, file-based transactional store.
- Investigate Redis as a distributed, in-memory option with persistence.
- Compare each option using criteria such as:
- Ease of integration with the current dataclass-based config model.
- Operational complexity and required infrastructure.
- Migration complexity from JSON file.
- Produce an ADR containing:
- Problem statement.
- Requirements.
- Options considered and their pros/cons.
- Decision and justification.
Alternatives Considered
- Do nothing: Keep using the JSON file.
- Custom binary format: More efficient but harder to maintain.
- Other databases: PostgreSQL or MySQL for larger-scale needs (likely overkill).
Additional Context
- The current config system is dynamic and supports placeholder resolution via
Resolvabledataclasses. - The backend storage should preserve existing behavior (e.g., placeholder resolution, nested configs).
- Storage abstraction is recommended to allow backend swaps without changing application logic.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request
Type
Projects
Status
Todo