I think it would be nice to see this roadmap separated by topics. Like GraphQL, Slash/Cloud GraphQL, Dgraph Core, Tools(third party).
Kafka is made with Java, same as Neo4j.
Since one of the plus point of Dgraph is it’s written in Golang. Why not use a message queue that is written in Golang?
Checkout NATS being Incubated by Cloud Native Computing Foundation.
P.S. I feel like Dgraph team already knows this, but still I thought I would put it out here.
Kafka and RabbitMQ are very popular in their area. If the implementation is fine, I don’t see why not support it in the future for RabbitMQ or NATS. The language which they were built, doesn’t matter much. What matters is whether many of our users are using it. For example, if we have, for some crazy reason, several users using SOAP. Why not? it would be really crazy to implement, but “if it is popular, why not?”.
I fully 1,000% support this idea. This sounds similiar to what @mrjn mentioned in his latest podcast appearance about Dgraph supporting subscriptions for updates. This would really help with syncing with 3rd party tools or doing any kind of data migration between two systems.
I would’ve liked to seen Proposal Nested Object Filters for GraphQL rewritten as var blocks in DQL but I can work around it myself for now. Taking a brief look at Gremlin… if that gets implemented then maybe there would be possible workarounds using some gremlin as a custom resolver. It appears to be more object-oriented language based and I would assume it would get implemented with it’s own endpoint interpreted by custom go functions and not rewritten to DQL. It seems like a functional language like that would be better implemented directly to it’s correlating Go functions.
Hi, bro. will u guys let dgraph support multi edge? for example: Alice and Mary was univesity classmate, but except that, they also was primery school classmate and high school classmate. and these relationship both belongs to classmate.
Excited for CDC. I the realize first pass is targeting the biggest target (kafka), but would love if the team considers building that in a pluggable way. We’ve gone cloud native and ditching kafka for PubSub was a great decision for us
Regarding Keylines, I recently integrated both Keylines and vis.js with dgraph (via VueJS). I’m happy to share my lessons learned with the team as you tackle this.
@matthewmcneely That would be great! Could you share what you did in a separate Discuss topic?
Regarding “Integrations with Ecosystem”, what does “Load/stream data directly from SQL to Dgraph Cloud” mean for the community version, does it mean we can “Load/stream data directly from SQL to Dgraph Cloud” or does it mean “Load/stream data directly from SQL to Dgraph Cloud including on Premises installations”? Thanks for clarifying!
Please add this to the roadmap:
Sorry if this is a longer post - let me know if this is not the right place to ask these questions, and I can move this post elsewhere.
We’re evaluating dgraph (v/s postgres) for our upcoming project. Since a lot of value in our schema is in entity relationships, I think a native graph db is a better fit.
I’ve gone through fair bit of documentation. I’m wondering about roadmap status of the following features.
Graphql advanced query features - currently Graphql is supported but a few key features are missing like (recursive) graph traversals, arbitrary group bys etc. Really don’t want my team to learn both Graphql and DQL. And at first glance, Graphql seems to have cleaner syntax - esp in declaring the schema.
On the question of group bys. Can we group by on multiple predicates? Did not see this in the documentation.
Composite unique fields. This is currently not supported. How about composite indices?
Edge predicates or properties - I know of facets - but did not see an example in Graphql documentation. Is there support in Graphql schema?
Atomically mutating multiple unrelated things in a transaction. Is this possible? Maybe I missed an example.
Some kind of ORM support in Python ala SQLAlchemy.
Hi @na-ka-na welcome to the Dgraph forums! Let me walk you through some of your questions:
- DQL is like GraphQL. I would advise starting with GraphQL. Once you are familiar with GraphQL, DQL comes immediately. Check out dgraph.io/learn for more information
- Yes. You can group on multiple predicate
- Composite uniques are coming! As for indices, well, indices in Dgraph are a bit different from the SQL world. If you mean RDBMS style composite indices, you may not need them.
- No, GraphQL (in their spec) does not support edge predicates
- Yes. You can have multiple mutation blocks that do different things in each block.
- Hmm… not sure on that…
I think many people stumble when they come from a SQL world. I suggest going through this course and if you want I can also jump on a call to provide some help with your schema and other questions.
Some DQL features like recurse aren’t possible as far as I know in GraphQL context. Due to its hard Typed Schema model. You can’t do arbitrary queries without building an arbitrary Schema on the fly.
I’m not so sure about this. Unless we have added this support lately.
What is Edge predicates? Isn’t Facets anyway? We don’t use this terminology. Maybe Edge properties to indicate Facets. But using this can confuse sometimes in a conversation.
Hi! I see Gremlin on the 2021 roadmap (and on the 2020 roadmap before that). Where would be a good place to track/petition for support for Gremlin?
Why, if it’s of use:
I had dreams of Dgraph being a true graph backend-as-a-service, where GraphQL is the database. With facets in the wind and no plan for recursive traversals it’s becoming clear to me that that isn’t a practical reality any time soon.
So now I’m back to making the technology decisions I’d make with any graph DB, and one of those is query language. If I’m going to write some custom resolvers that hit my DB, I’d pick Gremlin over DQL. It’s standard, familiar, and portable (and–while this is purely preference–it’s actually a bit harder on me for DQL to be like-but-not-quite-the-same as GraphQL. I’m constantly confusing functions and directives!). I should probably even throw SPARQL in here.
Is this roadmap up to date?
There are several adoption blockers listed, but no indicators where in priority they are, or if they’re being actively worked on/due for release in 21.07; It looks like the original post with the list was last updated on Jan 13th.
(it was originally posted January 13th, last edited May 18. If you click the pencil by the
Jan 13 date on the original post you can see the edits.)
To echo the point though, can we get this updated with current understandings of timelines?
Thanks for the clarification, I didn’t realize the edit history was available under the pencil.
LDBC benchmark (2021-Q1)
Recently, I am doing some experiments based on ldbc_snb benchmark.
I want to know if you have implemented ldbc_snb benchmark for Dgraph? Could you please provide me a solution to run ldbc_snb benchmark on Dgraph?
Thanks for your kindly support and I’m looking forward to your early reply!
So please, can we get an update on the roadmap? and a realistic next release date… just so you guys know, you are losing credibility by the current handling of the roadmap, release dates, etc…