[stevevanhooser]

Closes #100.

Problem

q = q | Query(...) in a loop nests one OR per term. Three places on the search path recursed once or more per level, so a few hundred to ~1,000 terms raised RecursionError before the search ran:

where	frames per OR level	failed at roughly
Query.to_search_structure	2	1,000 terms (any OR)
SQLiteDB._search_doc_ids (an OR that isn't all base.id lookups)	2–3	330–500 terms
datastructures.field_search (brute force, Database.search)	1	1,000 terms

On main, to_search_structure on a 3,000-term chain built in a loop raises RecursionError.

Change

• datastructures.or_operands flattens a chain of nested ORs into its operands, left to right, using an explicit stack.
  • A negated OR (~or) stays a single operand, because the negation applies to its whole result.
  • Empty operands pass through unchanged; each caller treats them as before.
• _search_doc_ids and field_search take the union over those operands instead of recursing.
• Query._resolve_search_structure rebuilds the structure bottom-up with an explicit stack (_resolve_children / _resolve_node). The rule applied to each node is unchanged; the leaf rules moved to _resolve_leaf.

Tests

tests/test_deep_or.py runs at 3× the recursion limit (3,000 terms):

• searching a loop-built OR of ids;
• searching a loop-built OR of other terms;
• the same, ANDed with a session;
• field_search on a deep OR;
• the new resolver compared against a copy of the old recursive one on 300 random query trees (ANDs, ORs, ~ors, isa, depends_on, ~depends_on, '*');
• the same subquery reached twice;
• or_operands: operand order and ~or handling.

Local runs:

• black --check and ruff check are clean.
• pytest: 830 passed.
• Bridge coverage against the DID-matlab #232 branch: 0 problems.

DID-matlab

VH-Lab/DID-matlab#232 (0de9cf2) makes the same fix in MATLAB: it adds did.datastructures.orOperands, used by fieldsearch and did.database/search_doc_ids.

Bridge changes here:

• new entry orOperands ↔ or_operands;
• fieldsearch and database now point at 0de9cf2.

Merge DID-matlab #232 first, with a merge commit. Until then, 0de9cf2 exists only on that PR's branch.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Dv7SxVR8MCu3MKpUvwwUia

[stevevanhooser]

Bridge coverage vs DID-matlab is red on ada3e89, and this is expected until VH-Lab/DID-matlab#232 merges.

The check reports one problem:

orOperands: matlab_path does not exist: src/did/+did/+datastructures/orOperands.m

CI checks out DID-matlab main, and that file is added by #232. Every other check passes. Against #232's branch (0de9cf2) the bridge check reports 0 problems.

Dropping the entry from this PR wouldn't remove the red window, it would just move it. Once #232 merges, main here would go red with "MATLAB file has no bridge entry".

So the order is:

1. Merge DID-matlab#232, with a merge commit.
2. Re-run this check.
3. Merge this PR.

---

Generated by Claude Code