Settings & Configuration
Relevant source files
The following files were used as context for generating this wiki page:
The flext-dbt-ldif project utilizes a multi-layered configuration strategy to manage dbt (data build tool) transformations of LDAP Data Interchange Format (LDIF) data. This system encompasses Python-based settings for the application logic, dbt-specific project configurations for SQL transformations, and package metadata defined via standard Python tooling.
Configuration is centralized through the FlextDbtLdifSettings class, which serves as the primary gateway for runtime parameters. This is complemented by dbt_project.yml, which defines the structural and materialization rules for the generated dbt models across different layers (staging, intermediate, and marts).
Application Settings
The application layer uses Pydantic-based settings to enforce type safety and provide global access to configuration parameters. The FlextDbtLdif API facade initializes with these settings, facilitating a consistent environment for services like the UnifiedService.
FlextDbtLdifSettings
This class is responsible for fetching and validating global settings. It uses a ConfigDict with a specific environment prefix (as referenced in README.md) to allow overrides via environment variables.
# Initialization of the facade with settings
def __init__(self, settings: FlextDbtLdifSettings | None = None) -> None:
self.config = (
settings if settings is not None else FlextDbtLdifSettings.fetch_global()
)
self._service = self.Service(settings=self.config)
Sources: src/flext_dbt_ldif/api.py:38-43, README.md:32-32
Configuration Flow
The following diagram illustrates how settings flow from the environment and global fetch into the active services.
The workflow relies on valid settings to manage project directories and service metadata, such as the ldif_generator status.
Sources: src/flext_dbt_ldif/api.py:38-43, tests/unit/test_dbt_models.py:22-35
dbt Project Configuration
The dbt_project.yml file defines how the dbt engine interacts with the LDIF data. It specifies the target database profile, model materialization strategies, and schema naming conventions.
Model Materialization & Layering
The project structures models into distinct layers, each with specific configuration tags and materialization types.
| Layer | Materialization | Schema | Tags |
|---|---|---|---|
| Base | table | ldif | ldif, enterprise |
| Staging | view | ldif_staging | staging, ldif |
| Intermediate | view | ldif_intermediate | intermediate, ldif |
| Marts | table | ldif_marts | marts, ldif, business |
Sources: dbt_project.yml:32-58
Global Variables
Variables are used to parameterize SQL models and control environment-specific behavior.
| Variable | Default Value | Description |
|---|---|---|
start_date | "2024-01-01" | Initial date for data processing |
analytics_version | "1.0" | Version of the analytics logic |
ldif_schema | "raw" | Source schema for raw LDIF data |
database_name | "ldif_analytics" | Target database for transformations |
Sources: dbt_project.yml:65-78
Package & Build Configuration
The pyproject.toml file manages the project metadata, dependencies, and quality gate tool configurations. It defines the project as an integration class with a focus on data transformation.
Project Metadata
- Name:
flext-dbt-ldif - Version:
0.12.0-dev - Python Requirement:
>=3.13,<3.14 - Main Dependencies:
flext-core,flext-ldif,flext-meltano,pydantic>=2.13.3
Sources: pyproject.toml:23-45, README.md:5-5
Tooling Configuration
The project enforces strict code quality via various tool configurations:
- Ruff: Configured with a comprehensive set of linting rules (
select = ["ALL"]) and specific bans on certain APIs in favor offlext_clialternatives. - Pyright: Set to
typeCheckingMode = "strict"to ensure type safety across thesrcandtestsdirectories. - Coverage: Minimum failure threshold set to 20%.
Sources: pyproject.toml:132-137, pyproject.toml:343-348, pyproject.toml:500-502
Summary
Configuration in flext-dbt-ldif is a hierarchical system where Python settings.py manages runtime logic and Pydantic validation, while dbt_project.yml orchestrates the data transformation pipeline. This dual-layered approach ensures that application-level parameters (like project directories) and data-level parameters (like SQL schemas and materializations) remain distinct but coordinated. The entire lifecycle is governed by the strict quality gates and dependency management defined in pyproject.toml.