Restricting a dj.U() aggregation raises a bare AssertionError
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 40/100
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
HAVINGwithoutGROUP 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.
- Vorherrschende Sprache
- Python
- Sterne
- 197
- Forks
- 98
- Ø Merge
- 15 Std. 31 Min.
- Gemergte PRs (30 T.)
- 9
Entwicklungsumgebung
- Enthält ein Dockerfile oder eine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus datajoint/datajoint-python
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
datajoint/datajoint-python#1581 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
datajoint/datajoint-python#1539 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
database.name should namespace schema names on MySQL, as it does on PostgreSQLEvtl. vergeben @dimitri-yatsenko hat das vor 2 Tagen übernommen. Offenfeature
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 15/100
datajoint/datajoint-python#1582 ·
Maintainer antworten meist innerhalb von 1 Tag
-
A column copied by a foreign key loses the parent's core type (int32 becomes int)Evtl. vergeben @dimitri-yatsenko hat das vor 3 Tagen übernommen. Offen
Schwierigkeit 3/5 Ein halber Tag Anfängerfreundlichkeit 25/100
datajoint/datajoint-python#1578 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 Ein halber Tag Anfängerfreundlichkeit 65/100
datajoint/datajoint-python#1577 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in datajoint/datajoint-python
Ähnliche Issues
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
huggingface/smolagents#2976 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug Triage-Needed
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
FuRongJun-1999/dsh-memory#170 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
pgvector/pgvector-python#163 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
521xueweihan/HelloGitHub#3940 ·