document behaviour when id _eq: undefined or null
See original GitHub issueEverything worked well, but then on the client-side happened issue when selected for deletion item id
has become undefined
and as result, all items in the table was deleted:
{
variables: { where: { id: { _eq: undefined } } },
}
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:8 (3 by maintainers)
Top Results From Across the Web
How to Determine If Variable is Undefined or NULL in JavaScript
Answer: Use the equality operator ( == ). In JavaScript if a variable has been declared, but has not been assigned a value,...
Read more >How to check for an undefined or null variable in JavaScript?
I think the most efficient way to test for "value is null or undefined " is if ( some_variable == null ){ //...
Read more >$eq — MongoDB Manual
Specifies equality condition. The $eq operator matches documents where the value of a field equals the specified value. ... Specifying the $eq operator...
Read more >Need PowerShell script to check the variable, if the variable is ...
Need PowerShell script to check the variable, if the variable is undefined or Null or Empty. But I am getting the error.
Read more >Node.js v19.3.0 Documentation
Bugs or behavior changes may surprise users when Experimental API ... If the message parameter is undefined, a default error message is assigned....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Happened to me twice recently. Wasn’t a good situation. Would be good to have this explicitly documented.
I think this could be fixed by preventing nullable types from being compared with some operators (e.g.
{_eq: X }
requiresX
to be some typeY!
). The reduction from{ _eq: null }
to{}
is unintuitive to those unfamiliar with ternary-valued logic in SQL, especially when the column being compared is non-nullable. My 2 cents is that exposing this as a type error is a far more elegant solution to now.