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

Restricting a dj.U() aggregation raises a bare AssertionError

未关闭
  • 哪里不对？
#1,580 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
40/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
mysql, postgresql, python, sql
领域
databases

调研方向

The failing assertion is in Aggregation.make_sql in expression.py near line 1358, and the PostgreSQL subquery gate uses _grouping_attributes; read condition.py for the no-common-attributes restriction semantics. First reproduce with dj.U().aggr(File, n="count(*)") & "n = 3" on MySQL. Done when the assertion is gone, the HAVING and subquery paths both return correct rows on MySQL and PostgreSQL, and tests cover string and dict restrictions with matching and non-matching counts plus restricting another table.

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

描述

Restricting a universal aggregation, dj.U().aggr(...) & <condition>, raises an AssertionError with no message, on any backend. The aggregation itself returns the expected single row; only the restriction fails, including when the restricted aggregate is used to restrict another table.

Versions: v2.3.4 and master at 68fdea59, MySQL 8.0.

Reproduction

@schema
class File(dj.Manual):
    definition = """
    file_id : int32
    ---
    filename : varchar(255)
    """

File.insert([(1, "a_part1.dat"), (2, "a_part2.dat"), (3, "a_meta.json")])
total = dj.U().aggr(File, n="count(*)")

total.to_dicts()                      # [{'n': 3}]
(total & "n = 3").to_dicts()          # AssertionError
(total & {"n": 3}).to_dicts()         # AssertionError
len(File & (total & "n = 3"))         # AssertionError

Expected: (total & "n = 3") returns [{'n': 3}] (and [] when the count differs), and File & (total & "n = 3") keeps every row of File when the restricted aggregate is non-empty and none when it is empty, as restriction by an expression with no common attributes does elsewhere (condition.py, "without common attributes, any non-empty set matches everything").

Cause

Aggregation.make_sql (expression.py:1358):

assert self._grouping_attributes or not self.restriction

A restriction on an aggregation is emitted as HAVING (MySQL) or as an outer WHERE around a subquery (PostgreSQL), but both paths assume grouping attributes exist. The PostgreSQL branch is also gated on them (use_subquery_for_having = ... and self._grouping_attributes).

Proposed fix

  • Remove the assertion.
  • MySQL: emit HAVING without GROUP BY, which MySQL accepts for an ungrouped aggregate and which may reference the select alias (SELECT count(*) AS n FROM t HAVING n = 3).
  • PostgreSQL: take the existing subquery path whenever the aggregation is restricted, with or without grouping attributes.
  • Tests: restrict dj.U().aggr(T, n="count(*)") by a string and by a dict, on both backends, with matching and non-matching counts; and restrict another table by the restricted aggregate.

Workaround

Wrap the aggregate in a subquery before restricting it:

gate = dj.U().aggr(File, n="count(*)").make_subquery() & {"n": 3}
File & gate      # all rows when the count is 3, none otherwise

len(gate) still fails on this form; see the companion issue on len() of an expression with an empty primary key.

主要语言
Python
星标
197
派生
99
平均合并
1 天 11 小时
30 天内合并 PR
10

环境准备

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

从这里开始

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

datajoint/datajoint-python 的其他 Issue

查看 datajoint/datajoint-python 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

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