NuDB
NuDB copied to clipboard
Add 'insert' command to nudb tool
This can be used to write tests in a scripting language (e.g. bash).
I started to implement this out of personal interest, however there seems to be a bit of an issue with "keys" vs. "key files":
Paths to .key files are parsed as "key,k", even though they are not related to (or contain) actual keys in any way. I could now either rewrite existing stuff to use something like "keyfile,kf" or invent another name for actual keys (used in key/value pairs) like "datakey,dk" which seems a bit awkward (and clashes with data files...).
As far as I understand it, the ".key" file actually is anyways more like an index? It probably is a bit too late to change naming at this point (e.g. nudb.dat, nudb.idx, nudb.wal?), but the whole "key file" stuff seems to me a bit weirdly named. Keep in mind though that I'm not a database or linear hashing expert and might just confuse some standardized naming.
The "key file" is just the name of the file that holds the index. You can use any file name you want, it doesn't have to end in ",key".
Or do you mean that the command line switch uses --key
and -k
?
https://github.com/vinniefalco/NuDB/blob/master/tools/nudb.cpp#L122 <-- this seems to be used further down in do_info/do_recover/do_rekey etc.
That's just the name of the command line switch, you can use any extension that you like for the files (or am I misunderstanding?)
The usage pattern
insert <dat-path> <key-path> <log-path> --key=<hex-key> --value=<hex-value>
would for example internally parse to the map {"dat":"path/to/nudb.dat","key":"path/to/nudb.key","log":"path/to/nudb.log","key":"0x1234","value":"0x1337","d":"path/to/nudb.dat","k":"path/to/nudb.key","l":"path/to/nudb.log"} (in JSON notation) leading to a clash since both the key-file and the key/value-key should logically be mapped to "key".
I could map the key-file to "index,i", but that then would be the only place in the repo where the "key file" is called "index file". It could also be called "keyfile,kf", still requiring some changes to existing functions but keeping the name.
Alternatively I would have to invent some strange name to refer to the key/value key and keep the existing "key" name for the key-file name. Since this file doesn't contain actual keys in the key/value sense anyways, the naming of that file seems a bit confusing.
Another alternative would be to just take a "data" string that contains key and value + a separator char (e.g. "--data=0x1234:0x1337").
or you could read hex strings delimited by tabs or newlines from standard input...
I'm not an expert in boost::program_options
or putting together nice command line interfaces
Me neither! ;-)
I'll just go ahead with "keyfile,kf" for now, the exact usage for that tool is not really documented anyways so it is unlikely that it breaks anyone's bash scripts downstream.