DGraph binary needs 4 parameters to run the service
mutations dir, postings dir, port, UIDs dir.
My proposal is all of them should have default values. So the user just needs to run the binary without any arguments.
The default config should be stored in ~/.dgraphrc by default or /etc/dgraph/dgraph.conf.
The user has to pass a path to a new config file to run dgraph under different options.
The directories for postings, mutations, UIDs can be in ~/.dgraph folder.
In Production, When there is a large amount of data, they have to be separate. For trial runs and debugging, this is pretty simple to work with.
Also having a config file will help us scale the codebase better if new options have to be added.
What we could do is to have another flag which can set values for these directories, like so:
parent_dir/m
parent_dir/p
parent_dir/u
iff those flags aren’t specified separately. That would cut down on the number of flags required to 1, i.e. the parent dir. Port already has a default value.
IMO, using a hidden directory in the home is a good choice for desktop tools/editors, but a bad choice for a database. At some point, I reckon we might need a conf file, but it makes it too easy for developers to put in too many knobs without thinking hard about whether they’re needed or not. For those reasons, I say we do the conf file lazily only when all the command line flags are required, and there are too many of them to be input manually.
Until then, we do what you’re doing here, i.e. figure out better ways to decrease the number of command line flags required.
@minions: Please add your advice on this topic, so @sreeramb93 can make an informed decision.
Agree we can have a flag for a parent directory with a default value of ~/dgraph. Then we can create these directories for mutations, posting lists and UIDs if they don’t already exist.
I’m wary of assuming that user’s home folder is where the data should go. A better behavior would might be to log fatal if we’re missing values for these folders.