- Boolean support in RBAC
- Filtering parent Nodes with Children properties without cascade
- Array support (duplicate and orderable)
- JS hooks pre/post generated queries/mutations. (Not just replacing with lambda resolvers)
- Enhancements on ordering (not sure of best solution here yet)
- String functions
- Datetime functions
- Pagination with Cascade support
- Multitenancy (we are doing this ourselves with a prefix and it’s not super) Doing this in the foss version would be the real gift.
- gRPC streaming mutations and gRPC streaming responses. Heck just gRPC the whole shebang.
- string manipulation functions would be a nice to have.
- we have to do a sad amount of extra work to filter edges by lists of (time)ranges. In the current system that would mean supporting lists as facets and supporting a range predicate with filters that could work on it… Ok that’s a big one but it would remove 2/3 of our graph.
@amaster507 Christmas came early for you . This has already been merged in master and should go out in next release
Also I have seen this requests that will be great to see:
- Distributed predicates
- Continue bulk/live from where is stopped earlier
- Composite indexes like unique on composite fields
My only wish in 2021 is Loops in DQL!
I’m a noob, so mine could all be there and I just haven’t noticed yet lol.
- @recurse on non-root blocks would be tops
- hot re-index. Even at some expense, but not stop-the-world.
default values support for graphql. Right now you can do it with lambdas but it’s a pretty crazy thing to do.
Multi Tenancy
CDC
Integration with Kafka
these are more important for me. and the system stability is also important.
Ahhh… Could be a docs issue. I’d have to find the part that led me to that (or… That I misread). Trying to find it again, I see some changes in 1.12, and MR#4819 with bg index.
My Santa came early. …last spring lol.
default values with a directive would be much better. Right now a default value with lambda requires a custom mutation which then you lose the benefit of creating deeply nested data in a single mutation. You couldn’t for instance create a author with a post and have a default value on the post unless now you created two lambda mutations, one for just a new post and one for a new post with author.
- [DQL] Sort indexes, or anything to improve the below issue:
Offset-based pagination is slow
Usecase: user feeds with infinite scroll - [DQL] Random nodes function
Pick random node
Usecase: friend recommendations - [DQL] tf-idf scoring on term search
Feature request: full text search with tf-idf Scoring - [DQL] Unique indexes
- [DQL] Composite indexes
- [DQL] Geo Distance function
Add @distance for geo
That’s correct.
@trka https://dgraph.io/docs/query-language/schema/#indexes-in-background is what you’re looking for
Deep Patch mutations.
References:
Ability to do atomic mutations without DQL
GraphQL has too many restrictions. I hope DQL can be more powerful and compete with the top graph database.
-
I hope there can be synchronous transactions, which can directly sense that the transaction has been completed.
-
More detailed log information, such as downtime log.
-
Java connection management: after the node is down, the connection of the node will be skipped. At the same time, the connection will be restored after the node is restored.
-
The cluster can have higher stability for concurrent requests. Now there will be node downtime and connection exception.
One more for me: Ratel… needs love.
I would love to see in Slash GraphQL
- Support for more AWS regions, at least add in US East
- AWS VPC Peering, the Mongodb Atlas service does this very well
For Slash GraphQL
- Relationships & auth builder in visual schema builder
- Data Explorer - for quick data inspection & debugging
- Environment variables for lambdas
- Default values in schema