Restricting a dj.U() aggregation raises a bare AssertionError
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 40/100
Direção de pesquisa
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.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Python
- Estrelas
- 197
- Forks
- 98
- Merge médio
- 15h 31min
- PRs com merge (30d)
- 9
Preparar o ambiente
- Inclui um Dockerfile ou arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de datajoint/datajoint-python
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
datajoint/datajoint-python#1581 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
datajoint/datajoint-python#1539 · 3 comentários ·
Mantenedores costumam responder em até 1 dia
-
database.name should namespace schema names on MySQL, as it does on PostgreSQLTalvez já em andamento @dimitri-yatsenko assumiu há 3 dias. Abertafeature
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 15/100
datajoint/datajoint-python#1582 ·
Mantenedores costumam responder em até 1 dia
-
A column copied by a foreign key loses the parent's core type (int32 becomes int)Talvez já em andamento @dimitri-yatsenko assumiu há 3 dias. Aberta
Dificuldade 3/5 Meio dia Facilidade para iniciantes 25/100
datajoint/datajoint-python#1578 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 3/5 Meio dia Facilidade para iniciantes 65/100
datajoint/datajoint-python#1577 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de datajoint/datajoint-python
Issues semelhantes
-
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 87/100
adri0/scadustats#128 ·
Mantenedores costumam responder em até 1 dia
-
`TIMESTAMP`, `TIMESTAMP_NTZ`, `TINYINT` and the other `TypeDecorator`s don't declare `python_type`Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
RPBCAbertaawaiting policy acceptance precheck-passed
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 78/100
Bioconductor/BiocContributions#240 · 1 comentário ·
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
documentation good first issue launch
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 83/100
FlologixAI/etchwork#4 ·