Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#1,580 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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分
マージ済み PR(30日)
9

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

datajoint/datajoint-python のほかの issue

datajoint/datajoint-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。