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 “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!
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! 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?
There’s a few comments by @mrjn in #8479 and there’s this closer from @chewxy#9554, and there is some discussion from ancient threads (2016-2019). These don’t seem like the right place.
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.
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.
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!