Santa wish list for Dgraph in 2021

  • 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
4 Likes
  1. 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.
  2. gRPC streaming mutations and gRPC streaming responses. Heck just gRPC the whole shebang.
  3. string manipulation functions would be a nice to have.
  4. 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 :stuck_out_tongue:. This has already been merged in master and should go out in next release :partying_face:

Also I have seen this requests that will be great to see:

  1. Distributed predicates
  2. Continue bulk/live from where is stopped earlier
  3. Composite indexes like unique on composite fields
3 Likes

My only wish in 2021 is Loops in DQL!

3 Likes

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.
1 Like

Re-indexing already allows a “background” option. Correct me if I’m wrong, @ibrahim

1 Like

default values support for graphql. Right now you can do it with lambdas but it’s a pretty crazy thing to do.

1 Like

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.

That’s correct.

@trka https://dgraph.io/docs/query-language/schema/#indexes-in-background is what you’re looking for :slight_smile:

1 Like

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.

1 Like
  1. I hope there can be synchronous transactions, which can directly sense that the transaction has been completed.

  2. More detailed log information, such as downtime log.

  3. 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.

  4. 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
2 Likes