`{}` evaluating to true is confusing

{} evaluating to true especially with where is confusing. We had cases which a frontend bug caused one variable to be undefined and the query was sent with where: {} instead of where: {key:value} and the entire table got cleared (acepsc).

#701 is also due to where: {} matching all the rows.

We need a special construct to match all the cases (that evaluates to true). An empty {} should mean nothing so that we can avoid accidental wiping out of the entire table using where: {}. This is bound to happen with frontend languages like JS and we should be a little forgiving there as it is our primary target.

[lexi-lambda]

I propose that we fix this as part of #4111. This would be a breaking change, though as has already been discussed, it seems just as likely that any situations where it comes up are bugs, not intended uses. I believe the potential for harm is significant enough that we should make the change, but if we receive reports of breakage during beta, we could add a temporary flag to re-enable the old behavior.

Our current solution in #4111 is more sophisticated than what has been described in this thread so far, and I believe it addresses the mentioned concerns in a neat way. Here’s the overview:

• We do not change the behavior of where: {}—if you write that in a query, it is equivalent to no where argument at all.

• Likewise, we do not change the behavior of where: {foo: {}}, which behaves the same as where: {}.

• We do change the behavior of where: {foo: {_eq: null}}. This is now an error; it is not equivalent to omitting the _eq completely.

This is intensely strange from the perspective of the GraphQL type system, since the type of the _eq field remains nullable. As discussed above, it has to be, or it could not be omitted. But we reject any situations where a null value is actually passed with an error that says we expect a non-null value.

This behavior is explicitly permitted by the GraphQL specification. From the section on Input Objects:

If the value null was provided for an input object field, and the field’s type is not a non‐null type, an entry in the coerced unordered map is given the value null. In other words, there is a semantic difference between the explicitly provided value null versus having not provided a value.

Emphasis mine. Again, this is completely bizarre from the point of view of the GraphQL type system, but it is completely logical from the point of view of the user! The user does not think of _eq as accepting a nullable column, they think of it as an optional argument that accepts a non-nullable column. The GraphQL type system treats these identically, but the specification gives us an out: we can’t give them different types, but we can give them different semantics.

This neatly solves the common problem where a variable accidentally ends up undefined, since we would now fail with an error, not delete the user’s database. At the same time, if someone explicitly writes code to omit the condition completely, we accept it. This seems like it’s clearly the right behavior to me.

[maxpain]

Every time I see breaking changes like this, which break ever more or less big project I think nobody from Hasura Team uses their product in their own projects. Maybe it is ok for a regular “Todo list” (lol)… IDK.