Closed jackfischer closed 9 months ago
Yeah,
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
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.
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.select Example { name } filter exists .name
name
is inferred as at most one (string | null
in typescript query files where we actually hit this)Schema: