I see. Every “entity” or “node” has its own ID but the id is global. So every “dataset” is of a variable type but gets its own autoincrementing unique id assigned.
So translated to a mongodb it’s like one giant collection, there are not different “tables”/“collections”.
Only that the connections between the fields are connected by a “descriptor”.
[node forum] -field- [attribute/node/leaf title]
One large collection and you mentioned namespaces?
The identifier uint64 seems large but when there are different types of data all using the same global id IMHO the identifier needs something that is more alike a bson.ObjectId aka something that can not overflow, as it has a time and counter (and a machineid) component in it. I understand that if 10 billion people would make 100 posts every day it would still take a couple of 100s of 1000s and more years to reach id overflow but what if? What if you have something like facebook that also have movie data and location data and all kinds of data and what if you have all the public/open data feeds in your graphdb? Maybe make it a time+uint64 string id. Or uint128
Sorry for being “lazy”, but when the 2nd command from the “Get started with docker” doc is ran, that is ran in foreground. When I run it with -d so it runs in the background the database is inaccessbile. Is there a way to just have dgraph running like with a --restart=always so it’s available all the time without needing to run the 2nd docker line in the background?
Also I see you’re building upon ubuntu:16.04(base) and then 14.04(release), wouldn’t it be better, since Go can be statically linked to have a FROM scratch. I mean, sure, if multiple docker images use ubuntu on the same host then it’s not an issue but if not then you have 200-600some MB of space wasted on a base OS you’ll never need. And the curl https://get.dgraph.io | bash could be done in Go with a helper. Still smaller than a whole OS.
Just a few thoughts. I’ll get to analyzing the code and putting it into corresponding functions now 