As much as I love DQL's capabilities, it would greatly simplify Outserv if it only had only one query language. That being said, we don't want to lose features.
Nested Filters
Nested filters are a complicated matter, but they seem to solve all the cases where you want to use var to search for something, and do something with the results. I believe if nested filters were done right, getting rid of dql would not be a problem. However, ALL nested filters use cases would have to be solved.
Aggregate Sort / Deep Aggregate Sort - It is worth noting that you would also need to sort by nested aggregates (sort by the count of nested fields, or deeply nested fields). This would have to be available, as it would be impossible without DQL.
Mutation Nested Filters - Nested filters are not just for queries, they are for nested filters and deep nested filters in mutations. These use cases are covered mostly in the upserts section below. This is why we really need custom dql mutations if you decide to get rid of dql mutations before nested filters are available in mutations.
query {
comment1 as var(func:type(Post)) @cascade {
Post.comment : Post.comment @filter( eq(comment.type, "excellent") AND gt(comment.likes,5) ) {
uid
}
}
post1 as var(func:type(Author)) @cascade {
Author.posts : Author.posts @filter(eq(Post.title, "Dgraph") OR uid(comment1)) {
uid
}
}
friends1 as var(func:type(Author)) @cascade {
Author.friends : Author.friends @filter((eq(Author.name, "Bob"))) {
uid
}
}
queryAuthor(func: type(Author)) @filter((uid(friends1) OR (eq(Author.name,"Alice") AND uid(post1)))) {
Author.name : Author.name
dgraph.uid : uid
}
}
The follower feed which is impossible in many database languages like noSQL:
This only covers the case where you may or may not have a record with an @id field, and you want to add / update it. This does not cover the case with an ID field in the record either.
However, the most useful case seems to be searching for multiple records, and doing something with them.
Conditionals - In my example here, you can see creating variables can work as IF statements
Nested Filters - You need nested filters in mutations to cover specific cases WHERE something does something here is another example
We do not want to break the GraphQL spec, or we end up with something like GraphQL+. We need Apollo Client or URQL Client to work, as it supports caching etc.
I'm sure there are more reasons and things to consider, but I think once nested filters are implemented on BOTH queries and mutations, most of them are solved.
As much as I love DQL's capabilities, it would greatly simplify Outserv if it only had only one query language. That being said, we don't want to lose features.
Nested Filters
Nested filters are a complicated matter, but they seem to solve all the cases where you want to use
var
to search for something, and do something with the results. I believe if nested filters were done right, getting rid of dql would not be a problem. However, ALL nested filters use cases would have to be solved.https://discuss.dgraph.io/t/rfc-nested-filters-in-graphql/13560
custom dql mutations
if you decide to get rid of dql mutations before nested filters are available in mutations.The follower feed which is impossible in many database languages like noSQL:
https://dgraph.io/docs/graphql/custom/dql/
Upserts
The biggest concern seems to be upserts. While technically DGraph's GraphQL currently has a type of upsert:
https://dgraph.io/docs/graphql/mutations/upsert/
Anthony's use case - https://discordapp.com/channels/826644093881942026/943970902650028102/946855151103250463
This only covers the case where you may or may not have a record with an @id field, and you want to add / update it. This does not cover the case with an ID field in the record either.
However, the most useful case seems to be searching for multiple records, and doing something with them.
GraphQL Spec / Functions
You may need DQL to do things like math / string / date functions - https://neo4j.com/docs/cypher-manual/current/functions/
We do not want to break the GraphQL spec, or we end up with something like GraphQL+. We need Apollo Client or URQL Client to work, as it supports caching etc.
I'm sure there are more reasons and things to consider, but I think once nested filters are implemented on BOTH queries and mutations, most of them are solved.
J