Re-indexing already allows a “background” option. Correct me if I’m wrong, @ibrahim
default values support for graphql. Right now you can do it with lambdas but it’s a pretty crazy thing to do.
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 - #6 by diggy
Usecase: user feeds with infinite scroll
- [DQL] Random nodes function
Pick random node - #9 by EnricoMi
Usecase: friend recommendations
- [DQL] tf-idf scoring on term search
Feature request: full text search with tf-idf Scoring - #8 by diggy
- [DQL] Unique indexes
- [DQL] Composite indexes
- [DQL] Geo Distance function
Add @distance for geo
@trka https://dgraph.io/docs/query-language/schema/#indexes-in-background is what you’re looking for
Facets variable in Upsert Block
The edges cannot be copied correctly now.
Deep Patch mutations.
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
Unique indexes for DQL. If I’ve created a schema using graphql and specified that a specific field is unique, e.g.
slug: String! @id, then it shouldn’t be possible to create a new node of that
dgraph.type with duplicate value assigned to that field/predicate.
Would be happy if Dgraph team announced that they are working on an offline-sync solution for mobile. What would make sense to me is to create a fork of MongoDB’s (Apache-licensed) Realm database, and then create some extensions for it so it can sync directly Dgraph Cloud. The only realistic alternative right now seems to be AWS App Sync which is super complex and involves creating a dedicated graphql API just for the mobile clients.
There is an initiative from the community for this. IHMO I think that offline support or even off in mobile is truly a complex situation. In terms of sync, overcopying and security. I don’t see Dgraph working on it on mid term.
You can use the Upsert Block logic to have this. Or even use the GraphQL feature. It is supported there.
Everything has it costs. No magic comes without pain. Something needs to be sacrificed I particularly prefer to stay on a consolidated model than invent the wheel and have an ultra-complex model that can lead to problems getting new engineers to maintain it. That’s my 2 cents if I would be a manager or even a CEO in a small startup. “Keep it simple”.
Before diving into some critical feedback, let me preface by saying dgraph is a very exciting database and, in general, I really love the (substantial) work so far.
I’ve been working on learning dgraph off-and-on for the past few weeks and so far I’ve found the documentation to be…lacking. Part of it is that I, personally, find DQL to be non-intuitive so that means I’m relying on the docs much more than I would when writing, say, Neo4j’s Cypher (which I generally find to be intuitive) or Firebase’s Firestore (which, admittedly, is a much less powerful query language than DQL but is also intuitive for me). But separately I do think the documentation just isn’t well thought out at this point.
This issue is a good example both because the “correct” DQL is highly counterintuitive to me and also because I don’t think that using DQL and GraphQL APIs together is well described in the docs (which apparently involves special considerations).
- Edit: I found that there is a section of the docs that describe using DQL and GraphQL together, but it’s called “GraphQL on Existing Dgraph”. What about someone who’s creating a new instance of dgraph that uses both DQL and GraphQL? So long as there are things you can only do with one API vs the other, I expect many apps will use both APIs. This is a pretty direct example of poor documentation. For example, renaming this section to “Using both DQL and GraphQL” would be an improvement and linking to this section from both the GraphQL and DQL docs, since you can’t predict where someone will start, would be another improvement (not sure why this concept is only mentioned in the GraphQL section–I generally find the GraphQL section to be more intuitive so I’ve been spending most of my time in the DQL section).
Considering how much time and energy must have been spent to getting dgraph to this point, it really seems like you’re shooting yourself in the foot by not spending more time on the documentation.
Similarly, calling edge properties “facets” instead of the more obvious “edge property” or “edge attribute” doesn’t seem like the best choice. I realize that edge properties have subtle differences vs node properties, but in this case I don’t think that justifies giving them a different, less intuitive name. Any time you find yourself giving something a name and then explaining what that name means to the reader, you should pause and ask yourself, “Why don’t we just drop the proprietary name and ‘use the intuitive explanation’ instead?” Some times there are reasons to rename something, but I don’t think “facets” reaches that bar.
Anyway, obviously there’s a lot of opinion here and again, despite frustrations I do really appreciate all the work that has gone into dgraph.
As a random musing: it just occurred to me that I’ve never heard of a development team practicing documentation first development (and I’ve never done this myself). I wonder how a project would turn out if you tried writing the docs first, as you would like to be able to describe the API, and then tried making the app. This is basically what UI driven apps do, when a designer designs the UX first and then codes the app to mimic that UX.
We are well into 21 but wanted to pile on my requests for even better search functionality.
- Wildcard search in full text, or clearer documentation on how to implement a real world user facing search interface. I would point to elasticsearch and their query language as something I have used successfully to implement a fairly user friendly and effective search interface.
- Custom scoring functions. I know BM25 is in the works but ultimately it should be customizable.
- Term match locations
- Support for vector searches to facilitate semantic search ala Vector-Based Semantic Search using Elasticsearch | by Sharanya Shenoy | Version 1 | Medium
- Standard or pluggable ANN vector searching capabilities such as HNSW, quantization, see http://ann-benchmarks.com/ also see Lucene’s ongoing work https://issues.apache.org/jira/browse/LUCENE-9004
- gRPC reflection that can detected by grpcurl - sample code from https://grpc.io/ works w/ grpcurl, but dgraph does not, need to copy api.proto everywhere
- this could be useful for a service mesh to know how to manage traffic
- integration/articles to leverage CDC with https://debezium.io/
- discovered usage of Debezium from article: Building a fault-tolerant event-driven architecture with Google Cloud, Pulumi and Debezium