Skip to content

Query-algebra spec: restriction by an expression with no common attributes, and restricting dj.U() aggregates #300

Open

Description

@dimitri-yatsenko

reference/specs/query-algebra.md leaves out two behaviors that the implementation defines, and misstates the matching rule for restriction by a query expression.

1. §2.5 states the matching rule as primary keys

Line 124: "Restrict to rows with matching primary keys in another expression." The implementation (condition.py, make_condition) matches on every namesake attribute the two expressions share, subject to the lineage check of semantic matching, not only on primary-key attributes.

Fix: state the rule as matching on common (homologous) attributes, and link §9 (Semantic Matching).

2. §2.5 omits restriction when the expressions share no attributes

§2.4 documents the dictionary case (line 103: "If NO keys match, condition evaluates to True"). The expression case is undocumented. The implementation treats it the same way (condition.py: "without common attributes, any non-empty set matches everything"):

  • A & B with no common attributes: all of A if B is non-empty, none if B is empty.
  • A - B with no common attributes: none of A if B is non-empty, all if B is empty.

This is what makes a global gate possible, for example Table & (dj.U().aggr(Other, n="count(*)") & "n > 0").

Fix: add the rule to §2.5 with an example, next to the dictionary rule in §2.4.

3. §8.3 does not cover restricting a universal aggregate

§8.3 shows dj.U().aggr(Student, n='count(*)') returning one row, and line 956 says restrictions after aggregation go to HAVING or a subquery, but neither covers restricting an ungrouped aggregate (dj.U().aggr(T, n="count(*)") & "n = 3"). In v2.3.4 that raises an AssertionError (datajoint/datajoint-python#1580), and len() of the subquery workaround raises a SQL syntax error (datajoint/datajoint-python#1581).

Fix: once #1580 is resolved, add a §8.3 example that restricts a universal aggregate and uses it as a restriction (rule 2 above). Until then, note the .make_subquery() workaround. The "Universal Aggregation (Single Row Result)" section of reference/operators.md (line 258) could take the same example.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions