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
分支
98
平均合併
15 小時 31 分鐘
30 天內合併 PR
9

環境準備

  • 提供 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 摘要。