And just to be clear. I understand that I can order the subgraph, but what is wanted and needed is ordering the parent graph based upon the data from the sub graph.
This is not possible natively in GraphQL and requires using DQL. Out of curiosity, since tags.tag can have multiple values per Contact, how do you expect this to be sorted? Is it like you’d want to sort by the minimum possible tag per contact, so if contact had tags a and z, you’d use a when doing ascending sort and z while doing a descending sort?
That is sort of the wildcard that I threw in there to show some complexity to the issue. The use cases really vary on this and it could be sorted by length of the array, or alphabetically of the first item in the set. Really I just wanted to show that a simple sort by Contact.cat would not be the same in essence of sorting by Tags.tag. Ideally one could supply a sort function. But that is lending towards a solution in a JS hook which again has its own complexities. Sorting already queried data would not honor pagination. I don’t have the perfect answer for this, just wanted to throw out there what I am trying to wrap my head around. Sorting in a relational database with joining data is very different from sorting in a graph.
Is it possible to provide a sample query on how to do this in DQL? For now I was only able to find this in the documentation, while I was hoping for something more like this.
Let’s say the schema is the following:
type Asset {
price: [Price]
}
type Price {
date: [Date]
}
type Date {
date: datetime
}
and we want to get the latest price of every asset (so sorting the prices by Date desc).
My understanding is that the @cascade directive forces the order from the nested nodes onto the parent—so in this case (orderdesc: val(dateValMap)) combined with @cascade means that the order of price: level is ‘filtered’ back up to the assetData level. Actually that doesn’t make sense because there is only one Asset in the above example, but the prices should be ordered by the nested dates. I don’t understand how this works, but it works on my machine™.
The complexity of rewriting the GraphQL to DQL would probably entail quite a bit. Very similar to why nested filtering is not in GraphQL but is possible with DQL.
It is simple when first looked at it, but when trying to get the schema right for all possibilities in the strictly typed GraphQL inputs it becomes difficult in my understanding.
the orderable type input would have to be able to be nested within itself to allow this.