A condition on a list read over several hops ignores a depth given for the query on the SQL stores, while the load honours it
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with drivine/backend/sql/sql_query_renderer.py:157, then compare its depth handling with drivine/backend/sql/sql_views.py:150 and drivine/dsl/query_renderer.py:304. Port ConditionDepthCrossEngineTest and ConditionDepthRenderingTest from the referenced work to cover query-specified depths, nested views, and rendered patterns. Done when conditions and loads agree across SQL and graph engines for the described depth cases.
由索引模型根据 Issue 内容生成。
描述
Port of liberation-data/drivine4j#461.
What happens here now. A condition on a list of fragments read over several hops (max_depth above 1) walks the field's depth on every store, but on the SQL stores it ignores a depth given for the query (depth={"following": 3}), while the load honours it. So the filter and the load disagree whenever a query gives a depth:
drivine/backend/sql/sql_query_renderer.py:157(the hop of a condition) takesdepth = rel.max_depth.- The load reads
self.depth.get(rel.field, rel.max_depth)(drivine/backend/sql/sql_views.py:150), and so does the Cypher condition (drivine/dsl/query_renderer.py:304).
With following of max_depth=2 over a → b → c → d and depth={"following": 3}, the load gives a's following as [b, c, d], and following.any(text == "d") doesn't find a on Postgres or Oracle; with depth={"following": 1} it finds a through c, which the load leaves out.
What the fix in drivine4j does (liberation-data/drivine4j#474): the load and every condition take the depth of a field from one place (RelationshipDepth.hops: the query's depth for the field, or its maxDepth, for a list of node fragments; one hop otherwise), on the graph engines and the SQL stores alike, at the top level and on a field of a nested view.
Tests that can be ported: ConditionDepthCrossEngineTest (the chain a → b → c → d, the cycle p → q → p, a stranger at the end and in the middle of a path, holders of the windows for a nested field; any, none, empty blocks, not, an or, depths 1 and 3 given for the query, and the count beside each filter), and ConditionDepthRenderingTest for the rendered patterns.
- 主要语言
- Python
- 星标
- 1
- 派生
- 0
- 平均合并
- 1 小时 29 分钟
- 30 天内合并 PR
- 136
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
liberation-data/drivine-python 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
liberation-data/drivine-python#250 ·
维护者通常 1 天内回复
-
bug
难度 1/5 1 小时以内 新手友好度 88/100
liberation-data/drivine-python#209 ·
维护者通常 1 天内回复
-
CI: three Oracle-only tests in test_cypher_compiled.py never run, as -k oracle doesn't select them未关闭
难度 1/5 1 小时以内 新手友好度 88/100
liberation-data/drivine-python#178 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 55/100
liberation-data/drivine-python#295 ·
维护者通常 1 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 65/100
liberation-data/drivine-python#294 · 1 条评论 ·
维护者通常 1 天内回复
查看 liberation-data/drivine-python 的全部 Issue
相似的 Issue
-
getchaintips leaves out the active tip once a header is staged on it, where Core always lists it未关闭
难度 2/5 1-3 小时 新手友好度 88/100
btclib-org/btclib-node#2158 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
dbt-msft/dbt-sqlserver#897 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
Gathin23/cleanyourtv#2770 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
vllm-project/vllm#64845 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 84/100
dekobon/big-code-analysis#1729 ·
维护者通常 1 天内回复