Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Query-algebra spec: restriction by an expression with no common attributes, and restricting dj.U() aggregates

未关闭
#300 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
半天
新手友好度
55/100
Issue 类型
文档
描述清晰度
基本清楚
活跃度
活跃
技术栈
python, sql

调研方向

Start with make_condition in condition.py to confirm the common-attribute matching and the no-shared-attributes rule, then edit reference/specs/query-algebra.md at §2.4 (line 103), §2.5 (line 124) and §8.3 (line 956). Also add the universal-aggregate example to reference/operators.md around line 258. Done means the matching rule is stated on common attributes with a link to §9, the empty-attribute rule has examples, and the universal-aggregate restriction is documented with the .make_subquery() workaround until datajoint-python#1580 is resolved.

由索引模型根据 Issue 内容生成。

描述

reference/specs/query-algebra.md leaves out two behaviors that the implementation defines, and misstates the matching rule for restriction by a query expression.

1. §2.5 states the matching rule as primary keys

Line 124: "Restrict to rows with matching primary keys in another expression." The implementation (condition.py, make_condition) matches on every namesake attribute the two expressions share, subject to the lineage check of semantic matching, not only on primary-key attributes.

Fix: state the rule as matching on common (homologous) attributes, and link §9 (Semantic Matching).

2. §2.5 omits restriction when the expressions share no attributes

§2.4 documents the dictionary case (line 103: "If NO keys match, condition evaluates to True"). The expression case is undocumented. The implementation treats it the same way (condition.py: "without common attributes, any non-empty set matches everything"):

  • A & B with no common attributes: all of A if B is non-empty, none if B is empty.
  • A - B with no common attributes: none of A if B is non-empty, all if B is empty.

This is what makes a global gate possible, for example Table & (dj.U().aggr(Other, n="count(*)") & "n > 0").

Fix: add the rule to §2.5 with an example, next to the dictionary rule in §2.4.

3. §8.3 does not cover restricting a universal aggregate

§8.3 shows dj.U().aggr(Student, n='count(*)') returning one row, and line 956 says restrictions after aggregation go to HAVING or a subquery, but neither covers restricting an ungrouped aggregate (dj.U().aggr(T, n="count(*)") & "n = 3"). In v2.3.4 that raises an AssertionError (datajoint/datajoint-python#1580), and len() of the subquery workaround raises a SQL syntax error (datajoint/datajoint-python#1581).

Fix: once #1580 is resolved, add a §8.3 example that restricts a universal aggregate and uses it as a restriction (rule 2 above). Until then, note the .make_subquery() workaround. The "Universal Aggregation (Single Row Result)" section of reference/operators.md (line 258) could take the same example.

主要语言
Jupyter Notebook
星标
7
派生
12
平均合并
2 天 19 小时
30 天内合并 PR
20

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

datajoint/datajoint-docs 的其他 Issue

查看 datajoint/datajoint-docs 的全部 Issue

相似的 Issue

更多 Databases Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。