edgedb / edgedb

A graph-relational database with declarative schema, built-in migration system, and a next-generation query language
https://edgedb.com
Apache License 2.0
13.07k stars 400 forks source link

Cardinality inference with filters #6694

Closed jackfischer closed 9 months ago

jackfischer commented 9 months ago

Steps to Reproduce:

I can only imagine this is difficult or impossible to do correctly in the general case, but for common, straightforward filters like exists .field, unnecessarily lax card inference is definitely some developer simplicity left on the table.

  1. select Example { name } filter exists .name
  2. name is inferred as at most one (string | null in typescript query files where we actually hit this)

Schema:

type Example {
  name: str;
}
msullivan commented 9 months ago

Yeah,

  1. It is (mathematically?) impossible to always have the narrowest cardinality in the general case
  2. This sort of case would be possible, though we don't currently have the infrastructure for refining shape elements based on a filter outside of them.

In general, though, we have a preference for maintaining a small, simple, and predictable set of cardinality inference rules. Currently we basically restrict filter based inferences to the core case of filtering on exclusive properties. One of the reasons for that is that changing the inference for something from multi to single can actually break user code, since if they were expecting a list/set and get a singleton, code will break.

Changing something from optional to required is pretty safe, though, so we could consider changes like these without much risk, though my inclination is still towards simplicity/predictability

jackfischer commented 9 months ago

Given that it would be a mess to do a part way job on anything else, understand the "preference for maintaining a small, simple, and predictable set of cardinality inference rules". Appreciate all the background information.