You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
aggr: a restricted group drops the rows with no match, though aggr keeps all rows by default #1650
A.aggr(B & cond, ...) keeps all rows of A by default (exclude_nonmatching=False, a LEFT JOIN). But when the group B is restricted, the restriction goes into the outer WHERE clause, after the LEFT JOIN. Rows of A with no matching row in B & cond then have NULL in B's columns, fail the condition and drop out, so the result behaves like exclude_nonmatching=True.
SELECT`parent_id`, count(child_id) as`n`FROM`aggr_repro`.`parent`LEFT JOIN`aggr_repro`.`child` USING (`parent_id`)
WHERE ( (color="red"))
GROUP BY`parent_id`
Projecting the restricted group first ((Child & 'color="red"').proj()) produces the same SQL and the same result.
The group's restriction belongs to the group. It should go in the join condition (LEFT JOIN child ON … AND color="red") or in a subquery for the group (LEFT JOIN (SELECT … FROM child WHERE color="red") AS …), not in the outer WHERE. Today a count of zero can't be expressed for a restricted group without dropping the row, and the documented default ("keeps all subjects, even those with 0 sessions") holds only when the group is unrestricted.
This is a logical error in the transpilation. Left join should trigger a subquery on the right operand if its restricted. Inner joins do not need such enclosure.
Activity
dimitri-yatsenko commentedon Nov 4, 2026
This is a logical error in the transpilation. Left join should trigger a subquery on the right operand if its restricted. Inner joins do not need such enclosure.