SQLFluff中LT02规则对Jinja语句缩进修复不一致的问题分析

SQLFluff是一款流行的SQL代码格式化工具，其中的LT02规则负责处理代码缩进问题。近期发现该规则在处理包含Jinja模板的SQL文件时存在修复不一致的情况。

问题现象

在特定场景下，当SQL文件中包含Jinja模板语句时，SQLFluff的LT02规则会反复切换两种不同的缩进要求。具体表现为：

1. 首次运行sqlfluff lint命令时，报告期望8个空格的缩进
2. 执行sqlfluff fix修复后
3. 再次运行sqlfluff lint命令时，又报告期望12个空格的缩进

这种不一致的行为导致格式化过程无法达到稳定状态，形成了一种"乒乓效应"。

问题复现

该问题在以下典型场景中可复现：

with raw as (
    select * from {{ ref('stg_test_test') }}
),

{% set group_titles = [
  ("name1", "name5"),
  ("name2", "name6")
] %}

final as (
    select
        product_id,
        {% for title, alias in group_titles %}
            MAX(IFF(group_title = '{{ title }}', group_flag, null))::varchar(1) as {{ alias }}
            {% if not loop.last %},{% endif %}
        {% endfor %}
    from raw
    group by product_id
)

select * from final

技术分析

这个问题源于SQLFluff在处理Jinja模板块时的缩进计算逻辑。在3.0.5版本中，引擎在处理以下结构时存在缺陷：

1. 对于Jinja的{% set %}声明块
2. 以及随后的{% for %}循环块

引擎在计算这些块的缩进级别时，未能正确考虑它们在不同上下文中的嵌套关系，导致缩进级别计算出现波动。

解决方案

该问题已在SQLFluff的3.2.3版本中得到修复。升级到3.2.5版本后，用户反馈问题不再出现。这表明开发团队已经改进了Jinja模板块的缩进处理逻辑，使其能够正确识别和维护一致的缩进级别。

最佳实践建议

对于使用SQLFluff处理包含Jinja模板的SQL文件，建议：

1. 始终使用最新稳定版本的SQLFluff
2. 对于复杂的Jinja模板结构，可以分步骤进行格式化
3. 在团队中统一SQLFluff的配置，特别是缩进相关的设置
4. 定期检查格式化结果，确保一致性

通过保持工具更新和遵循这些实践，可以有效避免类似缩进问题的发生。