Ash项目中自定义表达式在直接使用与计算包装时的行为差异分析

问题背景

在使用Ash框架开发Elixir应用时，开发人员发现了一个关于自定义表达式行为不一致的问题。具体表现为：当直接在读取操作中使用Ash.CustomExpression时，与将其包装在计算中再使用时，生成的SQL查询存在显著差异。

问题现象

开发人员定义了一个名为trigram_word_similarity的自定义表达式，用于实现PostgreSQL的word_similarity函数功能。该表达式在两种使用场景下表现不同：

1. 直接使用场景：在读取操作的过滤条件中直接调用自定义表达式时，生成的SQL查询缺少预期的过滤条件部分。
2. 计算包装场景：将自定义表达式包装在计算中，然后在过滤条件中使用该计算时，生成的SQL查询包含完整的过滤条件。

技术细节分析

自定义表达式实现

自定义表达式模块实现了Ash.CustomExpression行为，专门为PostgreSQL数据层定义了如何将Elixir表达式转换为SQL片段：

def expression(data_layer, [left, right]) when data_layer in [AshPostgres.DataLayer] do
  {:ok, expr(fragment("word_similarity(?, ?)", ^left, ^right))}
end

两种使用方式对比

1. 直接使用方式：

read :by_directly_matching_name do
  filter expr(trigram_word_similarity(name, ^arg(:term)) > 0.2)
end

2. 计算包装方式：

calculate :calc_word_similarity, :float, expr(trigram_word_similarity(name, ^arg(:term)))

read :by_indirectly_matching_name do
  filter expr(calc_word_similarity(term: ^arg(:term)) > 0.2)
end

问题根源

通过调试分析发现，当自定义表达式直接用于布尔表达式时，Ash的过滤器处理流程(Ash.Filter.hydrate_refs/2)会过早地对表达式进行求值优化，导致SQL片段被转换为Elixir值而非保留为SQL表达式。而在计算包装场景下，由于计算属性的特殊处理流程，表达式能够正确地保持为SQL片段直到查询生成阶段。

解决方案

开发人员发现了一种有效的变通方案：将布尔比较逻辑直接内置于自定义表达式中：

def expression(data_layer, [left, right, min_threshold]) do
  {:ok, expr(fragment("word_similarity(?, ?)", ^left, ^right) > ^min_threshold)}
end

这种方式确保了比较操作能够正确地转换为SQL条件，无论表达式是直接使用还是通过计算包装使用。

最佳实践建议

1. 对于需要在SQL层面实现的复杂条件，建议将比较逻辑直接包含在自定义表达式中。
2. 当自定义表达式需要与外部值比较时，考虑将比较值作为表达式的参数传入。
3. 在开发过程中，使用调试工具验证表达式在不同使用场景下的最终SQL输出。
4. 对于关键业务逻辑的查询条件，建议编写测试用例验证生成的SQL是否符合预期。

总结

这个问题揭示了Ash框架中表达式处理流程的一个微妙之处。理解这种差异有助于开发人员更有效地利用Ash的自定义表达式功能，特别是在需要与数据库特定功能集成时。通过将比较逻辑内置于表达式中，可以确保查询生成的一致性和正确性。