This tool lets you do basic things to a terminusdb instance, like storing and retrieving documents.
npm install -g @terminusdb/tdb-cli
Then,
tdb-cli setup
tdb-cli setup
will start an interactive setup tool to create your configuration.
tdb-cli is a new tool, so it cannot yet do everything that TerminusDB can.
The following subcommands are now implemented:
db
: create and delete databases and retrieve information about thembranch
: create, list and delete branchesdoc
: CRUD operations on documents in the databaselog
: shows the commit historygraphql
: launch a GraphiQL instance or get the schema for a resourcecurl
: run arbitrary curl commands using the endpoint and credentials in contextconfig
: utilities for querying and changing your configurationsetup
: an interactive setup tool for your configuration
Whenever possible, tdb-cli will try to infer what you're trying to work with from context. This context is usually your configuration file (~/.tdb.yml), but also includes top-level command line options, and environment variables.
Notably, the configuration file can have a current_context
configured. If you ran tdb-cli setup
, the last element you added
will be the current context, and will be what is used in all
operations.
If you have more than one context configured, you can explicitely
choose which one to use using the top-level option -c
like so:
tdb-cli -c myspecialcontext doc get myorg/foo
You can also switch to the context you like using
tdb-cli config context switch myspecialcontext
After that, myspecialcontext
will be used for all operations that
require a context without having to explicitely specify it.
To see what contexts are available to you, do
tdb-cli config context list
Most of the commands in this tool operate on databases, branches and more generically, resources. The way these are specified are uniform across commands.
This tool will use a combination of information in your configuration file, command line flags and finally the parameters of the command to figure out what resource to work with.
Without argument, everything is inferred from context.
If the single argument contains a /, it is assumed to be in the format <organization>/<database>
.
Example: tdb-cli db info myorganization/mydatabase
Otherwise, it is assumed to be a database name, and organization is taken from context.
Example: tdb-cli db info mydatabase
With two arguments, the first is the organization name, and the second is the database name.
Example: tdb-cli db info myorganization mydatabase
Without argument, everything is inferred from context.
If the single argument contains a /, it is assumed to be a path
leading to a branch. This is either <organization>/<database>
(in
which case the 'main' branch is inferred), or
<organization>/<database>/local/branch/<branch>
.
Example: tdb-cli branch create myorganization/mydatabase/local/branch/newbranch
Otherwise, it is assumed to be a branch name, and the organization and database will be taken from context.
Example: tdb-cli branch create newbranch
If there is more than one argument, the very last argument will be interpreted as the branch name, and everything before that as specifying the database.
Examples:
tdb-cli branch create mydatabase newbranch
tdb-cli branch create myorganization mydatabase newbranch
tdb-cli branch create myorganization/mydatabase newbranch
Without argument, everything is inferred from context.
If the single argument starts with branch/
or commit/
, it is
interpreted as referring to a branch or commit within the database
that is inferred from the context.
Examples:
tdb-cli doc get branch/mybranch
tdb-cli doc get commit/some_commit_id
Otherwise, if it contains a /
, or starts with a _
, it is
interpreted as a full resource path.
Examples:
tdb-cli doc get myorganization/mydatabase
tdb-cli doc get myorganization/mydatabase/local/branch/somebranch
tdb-cli doc get _system
If none of the above is true, the single argument will be interpreted as a database name, and the default branch of that database (main) will be used.
Example: tdb-cli doc get mydatabase
When not specifying a full resource path, the missing components will be taken from context.
If there is more than one argument, the last argument will determine how to interpret the previous ones.
If it refers to a branch or commit using the syntax described in the previous section, the previous arguments are interpreted as referring to a database.
Examples:
tdb-cli doc get mydatabase branch/somebranch
tdb-cli doc get mydatabase commit/some_commit_id
tdb-cli doc get myorganization mydatabase branch/somebranch
tdb-cli doc get myorganization/mydatabase branch/somebranch
Otherwise, the last argument is assumed to be a database, and the (single) previous command is an organization.
Example: tdb-cli doc get myorganization mydatabase
By default, the configuration file lives in your homedir at ~/.tdb.yml
. This can be overridden with the environment variable TDB_CLI_CONFIG_PATH
.
The configuration file is a YAML consisting of 3 sections:
endpoints
: all the endpoints you wish to connect tocredentials
: credentials to use while connectingcontexts
: configurations to use as defaults in tdb-cli
Finally, there's a field current_context
, which configures the
context used when not overridden.
Endpoints are a simple key value mapping from names to URLs.
Example:
endpoints:
foo: http://example.org
bar: http://example.com
There are four types of credentials:
- basic: Authentication with a username and password. This is what you'll most likely need for a self-hosted instance of TerminusDB.
- token: Authentication with a token. This is what TerminusCMS uses.
- anonymous: No authentication. This can be used with public endpoints. While allowed, you never actually have to explicitely configure this, as an implicit
anonymous
credentials is always configured. - forwarded: 'fake' authentication using the header
X-User-Forward
. This is sometimes used in scenarios where actual authentication is done using proxy middleware. You'll probably not need this.
These credentials are configured in a key-value map like so:
credentials:
foo:
type: basic
username: britney
password: chicken123
bar:
type: token
token: ..some long token here..
baz:
type: anonymous
quux:
type: forwarded
username: taylor
As a special case, the credentials named anonymous
(of type
anonymous
) is always assumed to exist. There is no need to
explicitely configure it.
A context describes which endpoint to use with which set of
credentials, and optionally configures a default team
, organization
,
database
and branch
.
The names used for the endpoint and the credentials correspond to the keys in the mappings described above.
Note that team
is only relevant in the context of TerminusCMS and
will not work out of the box with a self-hosted instance.
Example:
contexts:
foo:
endpoint: myendpoint
credentials: mycredentials
foo-defaults:
endpoint: myendpoint
credentials: mycredentials
organization: myorg
database: mydb
branch: somebranch
cms:
endpoint: TerminusCMS
credentials: mytokencredentials
# note that on TerminusCMS, team and organization tend to be the same
# unless you're collaborating across organizations.
team: myteam
organization: myteam
This is what tdb-cli setup
will produce for a self-hosted instance with credentials admin:root
and 'admin' as the default organization:
endpoints:
local: http://localhost:6363
credentials:
local:
type: basic
username: admin
password: root
contexts:
local:
endpoint: local
credentials: local
organization: admin
current_context: local