只问一次;HeavenBase 会路由问题,但仍希望你亲手打开答案。
1. 动机
应用代码应该描述数据意图,而不是选择 Provider 客户端或合并算法。 HeavenBase Query 是不可变请求值,由工作区结合 Entity schema、放置规则、Backend、handler 与 Context 策略进行解析。 构造过程不执行 I/O。 只有execute() 与 explain() 会跨越路由边界。
2. 构建不可变查询
hb.Query;这里没有可变的 QueryBuilder。
请像上面的 base 与 nearest 一样,用普通赋值创建分支。
to_spec() 返回路由使用的结构化不可变请求。
它不会选择 Backend,也不会执行 I/O。
3. 读取 ResultFrame
每次execute() 都会重新计算并返回一个新的 detached hb.ResultFrame。
结果不会被自动缓存或持久化。
rows()、scalar()、to_pandas()、to_pyarrow()、to_numpy()、to_pydantic() 或 to_daft() 等显式出口。
Frame 变换返回新 frame,访问器则返回由调用方拥有的值。
投影后仍保留 object_id,因此紧凑结果依然可以驱动后续 get、set 或 delete 调用。
4. 过滤与搜索
字段引用会构建类型化表达式,并通过&、| 与 ~ 组合。
contained_in(...) 执行反向包含:它询问哪些已存短值出现在更长的查询字符串中。
对于 Array[ShortText],SQL Backend 会在可用时使用 SparseGramIndex,并在保留的 match 元数据列中保存匹配关键词证据。
当无法证明 Provider 原生语义时,文本操作可能使用可移植 scan。
在用查询级 .unsafe() 以可移植性换取速度前,请先检查执行计划。
5. 接受 JSON 查询
query_json 会验证可序列化请求,并将其降低为同一个不可变 Query 值。
filter、available、near、traverse、select、group_by、aggregate、having、order、offset、limit 与 unsafe。
未知或过时的键会失败,而不会被忽略。
where() 也接受 Mongo 风格过滤映射,可使用 $eq、$in、$match、$contained_in 与 $array_contains 等已注册操作符。
6. 计数与聚合
count() 是仅针对数据源的终结 Query 规格。
它之前只能出现数据源过滤、搜索、遍历与 unsafe 策略。
aggregate(...) 后使用 having(...),并使用 order_by(...) 对结果排序。
路由可能执行 Provider 原生聚合或精确可移植 fold;explain() 会告诉你实际选择。
7. 检查执行计划
8. 让写入留在 Query 之外
Query 负责读取。 工作区 CRUD 拥有变更:entity=...。
总结
- Query 值不可变且惰性执行。
- 每次执行都会返回新的 detached ResultFrame。
- Python 与 JSON 表面共享同一个经过验证的请求模型。
- Explain 输出是实际路由行为的权威。

