You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, I know we could use negative conditioning instead of not operator, but providing built-in support for not operator comes handy when we are dealing with conditions using big list of values.
Also, the list condition (example: using 'in' operator) trying to convert into simple conditions using 'or/and' operators, which is ok with small list but against the large list !! this is not an efficient way to do that. so, providing straight forward solution to this will help. like following
{
lhs:{
typename:'Article',
fieldname:'id'
},
cmp:'in',
rhs:{
value:[] // for very large list
}
}
Classic example would be fetching all the repos(let's say 100+ repo under his id) of a user. if we'd support in operatory then the query conversion would be easy and efficient by using sql 'in' operator.
The text was updated successfully, but these errors were encountered:
Hi @trendchaser4u , I think (2) is a great suggestion, since the whole point of data filtering is to produce efficient queries. Could you give an example of what you mean by (1)?
I'm not a big fan of using not with in operator, but still we can't predict the use cases.
For argument sake I've a list of suppliers and want to fetch the list of products not from that supplier list,
like this..
let suppliers=[...]; //25 items
Select * from product p where p.supplier not in (...suppliers);
Yes, I know we could use negative conditioning instead of not operator, but providing built-in support for not operator comes handy when we are dealing with conditions using big list of values.
Also, the list condition (example: using 'in' operator) trying to convert into simple conditions using 'or/and' operators, which is ok with small list but against the large list !! this is not an efficient way to do that. so, providing straight forward solution to this will help. like following
Classic example would be fetching all the repos(let's say 100+ repo under his id) of a user. if we'd support in operatory then the query conversion would be easy and efficient by using sql 'in' operator.
The text was updated successfully, but these errors were encountered: