I see a traversal with @recurse returns nested structure. How can I get a response with retrieved nodes listed, not embedded into each other? @normalize only works at the very tail of nesting.
I mean, I need real graph with (nodes, edges), not graphQL output which is only OK for the end user.
You have only @normalize for now. Anything else can be done at the level of business logic.
Relational DB would be the better choice in this case I am afraid. What’s the point of Dgraph then? Your API leaves an impression your storage part is done right. But public API is nearly useless. You did a poor choice when stuck to object-based representation (which is a tree structure). Graphs cannot be represented in this way. This basically means dgraph is only useful for analytical workloads and nearly useless as a low level graph storage.
I’m sorry for your bad experience. However, I believe that normalize feature covers exactly what you want. If not so, please provide context in which I can analyze and identify the source of the problem and then take a suggestion for improvement.
Provide a graph DB as a distributed system.
Which public API? GraphQL? the HTTP API?
That’s the concept of a graph. I mean, not quite that. But the structure of the response you get is based on a graph structure. Internally, Dgraph works in a completely different way as the response itself.
A Graph is basically a structure fully linked by edges. And Dgraph does that natively.
Why not? that’s the only way. IMHO Any other way is a “hacky” representation of a Graph. e.g. “Tables” aren’t graphs.
From wikepedia:
In mathematics, and more specifically in graph theory, a graph is a structure amounting to a set of objects in which some pairs of the objects are in some sense “related”. The objects correspond to mathematical abstractions called vertices and each of the related pairs of vertices is called an edge.
That’s exactly what Dgraph does.
It is very rare anyone complaining about Dgraph in this way (I mean, everything you said in your answer). If you have good examples you can support that statement. Please feel free to share. I am not able to understand some of your statements in Dgraph’s context, except the meaning of the statements themselves.
So I need to understand why and see an example that supports these statements. Like another truly GraphDB “does like this, not like that and it is like this how graphs works”.
I’m pretty sure that normalize can “flat” your response as you wish.
Cheers.
Adding more info to the topic.
A simple way to have a “flat” response with recurse is to basically have two blocks.
Below is an example from the docs that I edited to represent this. The answer in the second block (block named “q”) is “flat” you need.
{
var(func: gt(count(~genre), 30000), first: 1) @recurse(depth: 5, loop: true) {
~genre (first:10) @filter(gt(count(starring), 2))
starring (first: 2)
ACTOR as performance.actor
}
q(func: uid(ACTOR)){
name@en
}
}
{
"data": {
"q": [
{
"name@en": "Paul Bowles"
},
{
"name@en": "Roger Rees"
},
{
"name@en": "Paul Stookey"
},
{
"name@en": "Peter James Bryant"
},
{
"name@en": "Richard Bradshaw"
},
{
"name@en": "Claire Bloom"
},
{
"name@en": "Megan Garrett"
},
{
"name@en": "Phil Grabsky"
},
{
"name@en": "Alan Ragains"
},
{
"name@en": "Mike Katz"
},
{
"name@en": "Donagh Gleason"
},
{
"name@en": "John Kagaihawa"
},
{
"name@en": "David Bickerstaff"
},
{
"name@en": "John Dean"
},
{
"name@en": "Donald Rumsfeld"
},
{
"name@en": "Wyeth Freaney"
},
{
"name@en": "Sibil Peeters"
},
{
"name@en": "Mary Travers"
},
{
"name@en": "Lanie Conklin"
},
{
"name@en": "Chris Huffman"
}
]
}
}
You can work it out in several ways. You just have to learn the language.
In the same block (“q”) you can add as many variables as you wish e.g:
{
var(func: gt(count(~genre), 30000), first: 1) @recurse(depth: 5, loop: true) {
G as ~genre (first:10) @filter(gt(count(starring), 2))
ST as starring (first: 2)
ACTOR as performance.actor
}
q(func: uid(ACTOR, G, ST)){
name@en
}
}