[Bug] Filter operators (contains, notContains, isEmpty, between) broken or inconsistent across frontend and server

[hotlong]

Summary

The contains text search filter returns no results while equals works correctly (see screenshot). After a thorough code audit, 7 related filter issues were identified across the objectui and spec repos.

Root Cause Analysis

Bug 1 (Critical): contains filter returns empty results — Server-side double-conversion

• Frontend sends AST: ['name', 'contains', 'Evan']
• Server parseFilterAST() converts to { name: { $contains: 'Evan' } }
• Driver receives { name: { $contains: 'Evan' } } but does not translate $contains → database-native (SQL/Mongo regex)
• Results are always empty.

Other issues:

• notContains operator missing from mapping tables
• isEmpty/isNotEmpty only matches null, not empty strings
• between filter renders only one input, needs min/max
• Case sensitivity inconsistency (contains)
• in/notIn operator expanded in frontend; drivers support natively
• Same double-conversion bug for startsWith/endsWith

Proposed Fixes

• Remove or refactor parseFilterAST() call and let drivers process raw AST arrays
• Ensure drivers (esp. Memory & SQL) correctly convert $contains, $startsWith, $endsWith, $notContains to native DB queries
• Update frontend FilterBuilder for correct input rendering & operator mapping

Reproduction

1. ListView/Contact, filter Name with Contains, value = 'Evan'
2. No items found; Equals with exact value works

Affected Files

• objectui and spec repos, details in full analysis

Cross-Repo Impact

Requires coordinated changes in both objectui and spec repositories (especially data engine drivers).

[hotlong]

Let me do a thorough audit of all filter-related code paths to identify any similar issues before creating a comprehensive issue.

好的，我已经完成了对两个仓库中所有过滤相关代码的全面排查。下面我来总结所有发现的问题，然后创建一个合并的任务。

🔍 全面排查结果

问题 1（原始报告）：contains 过滤器在服务端不工作

数据流完整追踪：

1. 前端 FilterBuilder → 用户选择 Contains，生成 operator: 'contains' ✅
2. ListView mapOperator() → 'contains' → 'contains' ✅
3. ObjectStackAdapter → 序列化 ['name', 'contains', 'Evan'] 为 JSON 发送 ✅
4. 服务端 parseFilterAST() → ['name', 'contains', 'Evan'] → { name: { $contains: 'Evan' } } ✅
5. 🔴 toQueryAST() → 直接透传 options.filter 到 ast.where，此时 filter 已经被 parseFilterAST 转换成了 { name: { $contains: 'Evan' } } 这种 MongoDB 对象格式
6. 🔴 Driver convertToMongoQuery() → 接收到的是 已转换的对象格式，走 MongoDB format passthrough 分支直接返回 { name: { $contains: 'Evan' } }
7. 🔴 Mingo 查询引擎 → Mingo 不认识 $contains 操作符！Mingo 使用 $regex 做模糊匹配，所以查询返回空���果。

根因：parseFilterAST 将 AST contains 转换为 $contains，但 Mingo 不支持 $contains。Memory Driver 的 convertConditionToMongo 方法能正确处理 contains → $regex，但 passthrough 分支跳过了这个转换。

问题 2：notContains 操作符缺失 AST 映射

function mapSpecOperator(op: string): string {
  switch (op) {
    case 'contains': return 'contains';
    case 'notContains': return 'notcontains';
    // ...
  }
}

notcontains 在 parseFilterAST 的 AST_OPERATOR_MAP 中 没有映射：

const AST_OPERATOR_MAP: Record<string, string> = {
  'contains': '$contains',
  'like': '$contains',
  // ❌ 缺少 'notcontains' 映射！
};

notcontains 会走 fallback 变成 $notcontains，而 Driver 同样不认识。

问题 3：startswith 操作符大小写不一致

前端 mapOperator 中没有 startsWith/endsWith 映射（FilterBuilder 未暴露这些操作符给用户），但 VALID_AST_OPERATORS 中同时存在 startswith 和 starts_with：

export const VALID_AST_OPERATORS = new Set([
  'contains', 'like',
  'startswith', 'starts_with',
  'endswith', 'ends_with',
]);

而 Memory Driver convertConditionToMongo 处理了 startswith/starts_with，但 AST_OPERATOR_MAP 映射到的是 $startsWith（驼峰），如果 filter 对象格式被 passthrough，Mingo 同样不认识。

问题 4：isEmpty/isNotEmpty 的 null 转换可能导致意外行为

function convertFilterGroupToAST(group: FilterGroup): any[] {
  const conditions = group.conditions.map(c => {
    if (c.operator === 'isEmpty') return [c.field, '=', null];
    if (c.operator === 'isNotEmpty') return [c.field, '!=', null];
    return [c.field, mapOperator(c.operator), c.value];
  });

isEmpty 被转换成 ['field', '=', null]，但服务端 parseFilterAST 会把它转成 { field: null }（简单等值），在 MongoDB 中这无法匹配空字符串 ""。正确的做法应该使用 is_null 或 $null 操作符。

问题 5：between 操作符前端无法正确传值

FilterBuilder 的 between 操作符在 defaultOperators 中定义了，但 renderValueInput 只渲染一个单值输入框——无法输入两个值（min/max）。

问题 6：in/notIn 的 normalizeFilterCondition 展开可能与服务端不兼容

export function normalizeFilterCondition(condition: any[]): any[] {
  if (op === 'in' && Array.isArray(value)) {
    return ['or', ...value.map((v: any) => [field, '=', v])];
  }

前端将 in 展开为 ['or', ['f','=','a'], ['f','=','b']]。但如果服务端 Driver 原生支持 in 操作符，这种展开是多余的且性能更差。

问题 7：DataScopeManager 的 contains 过滤区分大小写，但其他地方不区分

case 'contains':
  return typeof fieldValue === 'string' && fieldValue.includes(String(filterValue));

DataScopeManager 用 fieldValue.includes()（区分大小写），而 ValueDataSource 用 toLowerCase().includes()（不区分大小写），行为不一致。

---

现在创建一个合并的 Issue：