Problem
SQL analysis tools (sql_analyze, sql_format, sql_validate, sql_optimize) fail on Jinja-templated dbt SQL. For a dbt-focused tool, not being able to analyze {{ ref('model') }}, {{ source('src', 'table') }}, or {% if is_incremental() %} blocks is a significant gap.
Users working with dbt models must mentally strip Jinja before using analysis tools, and error messages don't explain WHY the tool failed on Jinja syntax.
Desired Behavior
SQL tools should handle dbt Jinja syntax gracefully, either by preprocessing it or by using dbt's own compilation when available.
Implementation Notes
Key Files
- SQL analysis tools in
packages/altimate-code/src/tool/ (sql-analyze, sql-format, sql-validate, sql-optimize)
- Python engine SQL methods in
packages/altimate-engine/
- Bridge client for adding preprocessing step
Approach
Phase 1: Jinja preprocessor (quick win)
Add a preprocessing step that stubs common dbt macros before passing SQL to analysis tools:
{{ ref('orders') }} → orders
{{ source('raw', 'events') }} → raw__events
{{ config(...) }} → (removed)
{% if is_incremental() %}...{% endif %} → (strip block)
{{ this }} → __this__
{{ var('start_date') }} → '__var_start_date__'
{# comments #} → (removed)
{% set x = ... %} → (removed)
{% for ... %}...{% endfor %} → (keep inner content)
This can be a Python function in the engine that runs before any SQL parsing.
Phase 2: dbt compile integration
When a dbt project is detected:
- Use
dbt compile --select <model> to get fully rendered SQL from target/compiled/
- Analyze the compiled output instead of the raw template
- This gives 100% accurate rendering including custom macros
Phase 3: Graceful fallback
For any SQL input:
- First try analysis as-is
- If parse error detected, check if input contains Jinja patterns (
{{, {%, {#)
- If yes, preprocess with Phase 1 stubs and retry
- If dbt project available, offer to use dbt compile for full accuracy
- Note in output: "SQL was preprocessed to remove Jinja templates — some analysis may be approximate"
Industry Patterns
- SQLFluff (Jinja templater): Renders Jinja with Python's Jinja2 library, has built-in dbt macro stubs for
ref, var, is_incremental()
- SQLFluff (dbt templater): Uses dbt itself to render SQL — most accurate but requires working dbt installation
- sqlglot: Does NOT handle Jinja (expects pre-rendered SQL) — confirms preprocessing is necessary
- SQLMesh: Offers SQL-native macro system as Jinja replacement
Acceptance Criteria
Problem
SQL analysis tools (
sql_analyze,sql_format,sql_validate,sql_optimize) fail on Jinja-templated dbt SQL. For a dbt-focused tool, not being able to analyze{{ ref('model') }},{{ source('src', 'table') }}, or{% if is_incremental() %}blocks is a significant gap.Users working with dbt models must mentally strip Jinja before using analysis tools, and error messages don't explain WHY the tool failed on Jinja syntax.
Desired Behavior
SQL tools should handle dbt Jinja syntax gracefully, either by preprocessing it or by using dbt's own compilation when available.
Implementation Notes
Key Files
packages/altimate-code/src/tool/(sql-analyze, sql-format, sql-validate, sql-optimize)packages/altimate-engine/Approach
Phase 1: Jinja preprocessor (quick win)
Add a preprocessing step that stubs common dbt macros before passing SQL to analysis tools:
This can be a Python function in the engine that runs before any SQL parsing.
Phase 2: dbt compile integration
When a dbt project is detected:
dbt compile --select <model>to get fully rendered SQL fromtarget/compiled/Phase 3: Graceful fallback
For any SQL input:
{{,{%,{#)Industry Patterns
ref,var,is_incremental()Acceptance Criteria
sql_analyzeworks on SQL containing{{ ref() }},{{ source() }},{{ config() }}sql_formatandsql_validatehandle Jinja syntax without crashingdbt compilefor full accuracy