[GROUP Query] Only singletons are allowed in using expression

[Androidown]

Currently query like

    group schema::ObjectType
    using
        base_name := .bases.name
    by
        base_name

would raise QueryError: possibly more than one element returned by an expression where only singletons are allowed, because .bases is a multi-link.

IMHO, it makes sense to use multi-link in using expression, and if it is allowed, GROUP query will be much more powerful.

For instance, a group query:

with g := (
	group schema::ObjectType
	using
	base_name := .bases.name
	by
	base_name
),
select g {
	key: {base_name},
	elements: {name}
} filter .key.base_name = 'schema::Pointer';

should produce the following result:

{
  "key": {"base_name": "schema::Pointer"}, 
  "elements": [
    {"name": "schema::Link"}, 
    {"name": "schema::Property"}
  ]
}

Actually I simply commented out _infer_singleton_only call in __infer_group_stmt and got the expected result 😮.

So I wonder if this is a design consideration that you guys think mult-link should not be supported, or is there any technical issue that blocks you from supporting such a feature?
Are there any plans to support multi-link in using expression?

[tailhook]

I think that the fundamental limitation is that every object must go into a single group. In your case it works well, since you're then filtering the single group later.

On your simple example, you can use regular select:

with
base_name := "schema::Pointer",
g := (
	SELECT schema::ObjectType
	FILTER .bases.name = base_name
),
select {
	key: {base_name := base_name},
	elements: (SELECT g { name })
}

Do you have a more elaborate use case that can't be written without GROUP?

[Androidown]

module default {
    type Person {
        multi link good_at -> default::Sports;
        property name -> std::str;
    };
    type Sports {
        property category -> std::str;
        property name -> std::str;
    };
};

insert Sports {name := 'basketball', category := 'ball game'};
insert Sports {name := 'soccer', category := 'ball game'};
insert Sports {name := '100m', category := 'track and field'};
insert Sports {name := '800m', category := 'track and field'};
insert Person {name := 'Mike', good_at := (select Sports filter .name in {'basketball', 'soccer', '100m'})};
insert Person {name := 'Jack', good_at := (select Sports filter .name in {'800m'})};

I think that the fundamental limitation is that every object must go into a single group.

I think it's fairly common in real world that same object goes into different groups. Take the above schema as example, a Person can be good at different sports, if we group Person by category of the sport each person is good at, we expect Mike goes into both ball game and track and field. That said, an edgeql query:

with g := (
    group Person
    using sports_category := .good_at.category
    by sports_category
)
select g { 
    key: {sports_category}, 
    elements: {name}
};

The above query might be rewritten as grouping Sports by category and using a good_at backlink to refer to Person, but I think this is the most straightforward one. Also, if we add another Person's property into the using expressson of Person's grouping query, it will be pretty hard to rewritten it by grouping Sports.

should produce the following result:

[
  {
      "key": {"sports_category": "ball game"},
      "elements": [{"name": "Mike"}]
  },
 {
    "key": {"sports_category": "track and field"}, 
    "elements": [{"name": "Mike"}, {"name": "Jack"}]
  }
]

The problem is that Mike is good at both basketball and soccer, so he might appear twice in group ball game using the compiled pgsql.