Sorting by count

Hi there.

I have “tag” nodes that are used to tag things. Now I need a tag list ordered by how many things of a given kind it is tagging.

{
  q(func: has(__is_tags)) @normalize @cascade{
    uid
    text: tagname
    ~tags @filter(has(__is_issue)){  # this should be the obvious way => (orderdesc: weight)
    	weight: count(uid)
    }
  }
}

Please, how can I do that. Multiple queries and / or parsing results via code again?

Thanks.

I believe that the documentation has something similar of how it should be done
https://docs.dgraph.io/query-language#sorting

~genre (orderdesc: val(numGenres)

Query:

{
  genres as var(func: has(~genre)) {
    ~genre {
      numGenres as count(genre)
    }
  }

  genres(func: uid(genres), orderasc: name@en) {
    name@en
    ~genre (orderdesc: val(numGenres), first: 5) {
      name@en
    	genres : val(numGenres)
    }
  }
}

Hi, Michel. Yes, I’ve been there before posting here and it not looks like the case.

Is there any plans on the roadmap to make those things a little bit more fluid? Maybe its just me, but I do not like this “splitng way” of doing queries, specially when I just want a simple “order by” on a very simple and straightforward query, not to mention that when it comes do retrieve heavy statistical data to feed a bunch of charts things can get ugly fast in that way.

Thanks.

In practice there are not two queries. Dgraph in the Var block collects the required UIDs and treats them in the next block. I think this logical separation is good for keeping the queries simpler. If we were to add different logics to the language this would eventually make GraphQL± impractical.

If you try to always use the Var block, you get used to it.

There are plans to slightly modify the language and make it strongly typed - but I do not know about the time range for work on it or any other detail.

I don’t know how to say it right, but I think there is a flaw in the concept in your thread question.
Look, by design it would not be possible to sort Parent by an Alias (or not) from a Child. A value that will still be produced/processed and belongs to a Child is not expected/predicted to classify the Parents nodes.

Having this in mind, you need to go through a Var block to be able sorting as you want. By a child value.

In addition

I think could add a feature sorting with Count Index at root (Count index is diff from Count uid in the enclosing block). Fill up an issue for this. This could be a real solution to your case. But keep in mind that Count Indexing costs a little.

https://docs.dgraph.io/query-language#count-index

The form count(predicate) counts how many predicate edges lead out of a node.

Cheers.

Well, this “by design” is exactly my point.

I think that an hypothetical GraphQL++ would care more about the first child relationship per branch in order to allow a greater flexibility in sorting and cascading things to extend a few. Many complex queries would be transformed to simple and intuitive ones with this approach when the first child result “feeds” the parent for such operations.

Its not even fair to compare DGraph with SQL, because SQL wont stand the minimal chance, BUT, in terms of “meta programing” it still beats GraphQL± when it comes to the need to make dynamic queries that can only be built with runtime info, and not a priori by the developer and hand coded into the app.

But, thats only me.

=]