Similar to this issue but here there’s no offset being used and the query is in DQL.
When adding sorting to a query, the number of nodes returned decreases significantly. I wrote a query that returned 2196 results without sorting and 414 results when adding sorting. The query uses @cascade but no pagination.
Cascade means something like “Return only those who match the request”. So, if the other values have no value in the sorting field target. It probably will be ignored. Check if that is true. You can’t point to an issue in a feature while using another feature in combination. I mean, you can, but the issue should be related to both at least.
Add a value to the other 1782 nodes.
Thanks for the reply. Note that both queries are cascading by the same fields and the predicate I’m using to sort (Product.currentPrice) isn’t in them. Furthermore, I verified there are only about 200 nodes that don’t have that predicate. So I still think there might be some sort of a bug here. I can share the full queries with you privately if needed.
EDIT: in case you haven’t, please take a look at this similar issue. There, the only difference in the query is changing the sorting from ascending to descending, which again, decreases the number of results
In the previous, you are using Product.uploadedOn - which I suppose to be DateTime? Have you checked if all of them have the correct date format?
What helps is reproducing with a small example. If you can’t reproduce with a controlled scenario, it might mean you have a messy dataset. Or a bad query.
Having a similar problem with “reduced number of results” when adding sorting.
The only difference between these two queries is the orderasc:year. Yet, they are producing different number of results. What could be the cause?
{
example( func: eq(cube,"cube2022", "cube2023"), orderasc:year )
@cascade {
cube
year
country @filter( eq(code, "SWE")){
code
}
}
}
Hi Daniel,
It is a good practice to open a new issue even if it is related to these questions. You can even put a link as a reference. But commenting in old issues provoque email triggering.
Maybe your data doesn’t have the predicate year in all nodes. Also, cascade filter those who don’t match the query body request.
There is a known bug/feature (depends on who you ask) that if you order by a field that is not available it doesn’t do logical NULLS first nor NULLS last, but rather NO NULLS.
Let me go find a linked article about this if I remember.
Here it is: Expected behaviour for sort queries
So it was agreed upon to “fix” this, but I still don’t think it was fixed yet. 
It is a good practice to open a new issue even if it is related to these questions.
OK! Will do for next issue.
Maybe your data doesn’t have the predicate year in all nodes. Also, cascade filter those who don’t match the query body request.
I believe it has the same predicates (doublechecked using has(predicate)). It seems it could be related to this. I am experiencing something similar, where I try to filter a lower level but it will only loop over 1000 items despite setting first: 1000000. It seems (as @iluminae writes) that the “orderasc” cancels out the possibility to filter all records before deciding on a final pagination limit:
Is there any ETA on when this will be fixed?
