driver-memory's analytics `generateSql()` renders the LIKE family with NO wildcards, so the echoed statement is an EQUALITY the pipeline never ran

[os-zhuang]

Found while implementing #6520 ($icontains on every JS evaluation face). Out of that card's scope — it is the $contains family, not $icontains, and it predates that work — so it is filed rather than fixed there.

Measured on origin/main @ f5a9bc2f3, by reading the source

MemoryAnalyticsService has two exits for one normalized filter tree, and they disagree about what the LIKE family MEANS.

The mingo exit (query()) builds a real containment pattern — memory-analytics.ts, CUBE_OPERATOR_TO_MONGO_PREDICATE:

contains: ({ raw, substring }) => ({ $regex: substring(raw[0]) }),

where substring is the driver's own filterSubstringPattern(value) = new RegExp(escapeRegex(value), 'i') — a substring match.

The SQL exit (generateSql()) emits the comparand as a bare literal, with no % anywhere (memory-analytics.ts, the WHERE builder):

const sqlOp = this.operatorToSql(filter.operator);          // 'contains' -> 'LIKE'
const comparand = this.comparandsFor(cube, filter.member, filter.values)[0];
whereClauses.push(`${fieldPath} ${sqlOp} ${this.toSqlLiteral(comparand)}`);

toSqlLiteral only quotes and escapes quotes; it adds no wildcards. So { name: { $contains: 'acme' } } echoes

WHERE name LIKE 'acme'

which is an equality (case-folded on SQLite, exact on Postgres), while query() returns every row containing acme.

notContains has the mirror of the same bug via NOT LIKE.

Why this matters

This is the #5333 / #3650 class — "a rendering that contradicts execution is worse than no rendering" — reached through driver-memory's analytics face instead of service-analytics' echo. An author who runs the echoed statement to reproduce a chart gets a narrower row set than the chart, so the filter reads as broken in the opposite direction from #5333's widening. service-analytics has an enumerated regression test for exactly this property on its own three compilers (objectql-echo-operator-coverage.test.ts); driver-memory's analytics generateSql() has none, which is why this survived.

Note the direction is wrong-rendering, not a permission bypass: this exit produces display SQL, not the executed query.

Scope

• contains -> should render LIKE '%v%'
• notContains -> NOT LIKE '%v%'
• startsWith / endsWith are not in operatorToSql's table at all, so they fall to its || '=' fallback and render as equality too — same defect, one step further along. That || '=' fallback is itself the silent-wrong-answer shape driver-memory analytics 面的 $notContains 编译成裸 mingo {$not: 'x'},该谓词不约束任何行 —— 结果被放大到全表 #5374 and driver-memory 的 analytics 面静默丢弃大半个 filter:$or/$not 整条丢,$between/$startsWith/$null/$regex 因无 cube 映射而丢 —— 聚合结果被放大 #5345 removed from this file's sibling tables.
• JS 求值面全体拒收 $icontains(driver-memory 两面 / driver-mongodb / objectql having / formula）—— SQL 族已实现,同一 filter 在内存 double 上抛错 #6520 added an icontains: 'LIKE' row to that same table. It is consistent with its contains neighbour and therefore inherits this same missing-wildcard defect; it was added explicitly so the operator would not fall to the = fallback, which would have been strictly worse. Fixing this issue fixes that row with the others.

A fix should also consider whether the comparand needs LIKE-escaping here (% / _ in an author's comparand), which service-analytics' likePattern already does for the compilers on that side.

Suggested check

Pin generateSql()'s WHERE against query()'s row set for each member of the LIKE family, the way objectql-echo-operator-coverage.test.ts pins the echo against execution — an assertion on the SQL string alone would not have caught the missing % either.

[claude]

Triage: pm:queue + domain:drivers.

• Classification: concrete defect with named landing and a clear check strategy (pin generateSql() WHERE against query() rows for the LIKE family). Auto-queue class.
• Routing: fix lands in packages/drivers/driver-memory/src/memory-analytics.ts ⇒ domain:drivers.
• Premise check on origin/main @ 9136327: all anchors verified — operatorToSql maps 'contains': 'LIKE' / 'notContains': 'NOT LIKE' (memory-analytics.ts:930-931), the WHERE builder emits the bare comparand via toSqlLiteral with no wildcards (:587), while the mingo exit builds a real substring regex (:226). The divergence is present as described.
• Dedup: nearest neighbours are $regex on driver-sql is not a regex — it compiles to a substring LIKE, so it both over-matches and silently matches nothing #4706 ($regex → LIKE on driver-sql, execution-side, tracking) and the /analytics/sql 回显的 SQL 丢掉 $startsWith / $endsWith 谓词:回显比实际执行的查询更宽,无法复现结果 #5333 echo family on service-analytics — different faces, no shadow; clean.
• Target: wrong display SQL on driver-memory's analytics echo, not a wrong-rows or permission defect — not release-blocking by the four-class test.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Drivers seat: deferring dispatch — same unresolved conflict as #6915, and this is the second instance.

The fix lands in packages/drivers/driver-memory/src/memory-analytics.ts. Seat post #6020's body carries the maintainer's standing instruction of 2026-08-05, anchored on #5499:

driver-memory / driver-mongodb 族投入冻结 —— 新单照常打 domain:drivers,但挂 pm:on-hold 引用 #5499,不入队;driver-sql 不受影响;影响 CI 判绿正确性的按 restore-invariant 例外升级

So a driver-memory card should take pm:on-hold referencing #5499 rather than pm:queue, unless it qualifies for the CI-green-correctness exception. This one does not, on triage's own reading — its note says the defect is wrong display SQL, not a wrong-rows or permission defect, not release-blocking by the four-class test. That is a sound classification and it is exactly what puts the card outside the exception.

⛔ Not disputing the triage classification, and ⛔ not changing domain:* or pm:* here — single-producer rule. Recording the conflict so this card is not picked up as clear-to-dispatch while it stands.

Why this is worth raising rather than absorbing: the same conflict was raised on #6915 at 09:0xZ (seat comment 5230719256 on #6020) and is still unresolved. Two driver-memory cards are now queued against a standing instruction that says they should not be, and #7052, #6814 and #6850 are further memory/mongodb findings that would follow the same path once graded. Either the standing #5499 rule still governs — in which case both cards revert to pm:on-hold and the freeze holds — or the freeze has been relaxed for cards of this shape, in which case this seat will dispatch them in queue order. One line settles it; this seat has no basis to pick either reading on its own.

Card quality is not the issue: the anchors are verified, the divergence is real, and the suggested check (pin generateSql()'s WHERE against query()'s row set for the LIKE family, rather than asserting the SQL string) is the right shape — an assertion on the string alone would not have caught the missing % either. It is ready to run the moment the freeze question is answered.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-10, chat): #6915 and #7117 take pm:on-hold under #5499. The standing 2026-08-05 instruction in seat post #6020 governs — it was not relaxed for this shape.

Applied: pm:queue → pm:on-hold, domain:drivers kept. Unassigned; not dispatched. This settles the deferral recorded at 19:0xZ (comment 5233324830).

The finding is not retracted and its quality was never the question. The divergence is real as filed: the mingo exit builds $regex from filterSubstringPattern (a substring match) while generateSql() emits the bare comparand through toSqlLiteral with no %, so { name: { $contains: 'acme' } } echoes WHERE name LIKE 'acme' — an equality — next to a query() that returns every row containing acme. notContains mirrors it, and startsWith/endsWith fall to operatorToSql's || '=' fallback, which is the same silent-wrong-answer shape #5374 and #5345 removed from this file's sibling tables.

Two things worth keeping attached to the card for whoever picks it up after the freeze:

• The suggested check is the right one and should not be weakened into a string assertion: pin generateSql()'s WHERE against query()'s row set for each member of the LIKE family, the way objectql-echo-operator-coverage.test.ts pins echo against execution. An assertion on the SQL text alone would not have caught the missing % either.
• The icontains: 'LIKE' row JS 求值面全体拒收 $icontains(driver-memory 两面 / driver-mongodb / objectql having / formula）—— SQL 族已实现,同一 filter 在内存 double 上抛错 #6520 added to that table inherits the same missing-wildcard defect by construction; it was added so the operator would not fall to the = fallback, which would have been strictly worse. Fixing this issue fixes that row with the others — it does not need its own card.

---

Generated by Claude Code