I dunno why you chose to editorialize the repo's summary (and thus the html title contents) away from the much clearer "Foundation DB Query Language" than what sounded like a generic KV query language whose readme launched right into talking about Foundation DB and never got around to any S3 specifics
Totally fair point. Although FQL is specifically designed for FoundationDB, I'm personally excited about using it as a generic syntax for querying other KV stores.
I don’t have any exposure to foundationDB except for the incredible endorsement of Aphyr saying they have a test suite so good he didn’t bother testing it with jepson. I’m shocked by the demo I just saw with FQL, when I hear KV store I assume I can only query by Key. This looks far richer. I’m not sure I understand what I’m seeing, can anyone actually using this DB explain?
You can only query by key (and key ranges). To work with the fact that FoundationDB just exposes keys as raw bytes, the FDB team developed a rather clever 'tuple' serialization protocol and standardized its presence in the different client bindings. This encoding lets developers turn a tuple of values into byte string that sort correctly, making them useful for creating indexes and other higher level layers such as directories. This library appears to be a nice CLI interface to working with those facilities.
Unless you were using these tools (tuples and directories) on top of another KV store, this query language probably wouldn't help much elsewhere. However, the tuple encoding scheme is rather straightforward and for doesn't depend on anything specific to FDB (aside from versionstamps but you just wouldn't implement those for another DB).
Versions are super important on any kv store that deals with concurrency. Without it, you can’t do any kind of concurrency control.
I was looking for possible inspiration for some kind of best practice to reduce the amount of information returned for wildcarded Redis queries (reduce it to just what's changing, or maybe some piece of what's changing). Didn't find it. Could be the documentation lacks clarity.
Every NoSQL ends up getting a QL.
"NoSQL" was always a terribly-named movement indicating a heinously-shallow view of data stores.
SQL is "Structured Query Language".
So yes, they get the QL without the S.