Connecting

A store opened with a path lives inside the process that opened it. One process, one store, no socket. That is the right shape for a script and the wrong one for an application, so the same binary will also serve:

$ tessaridb ./data --serve 0.0.0.0:7654

It serves until it is stopped. Add HTTP alongside, and one process holds both surfaces:

$ tessaridb ./data --serve 0.0.0.0:7654 --http 0.0.0.0:8000

Reaching it

$ tessaridb --at 127.0.0.1:7654
tessaridb> 

Note what is not there: no scheme. It is --at and not --url because this protocol has no scheme, and calling an address a URL promises one that does not exist. A bare host:port is the whole address.

The prompt is the same prompt. The store is in another process now, and the answers are rendered by the same code either way — so what is printed does not depend on which of the two you used. That is a property of the code's shape rather than a claim about it: both paths reach one renderer.

The moment a store closes

A store with no user is open, and anything may run against it. That is not an oversight — requiring a sign-in against a store with no accounts locks everybody out with no way in to fix it.

Declaring the first user is what closes it:

DEFINE NAMESPACE prod;
USE NAMESPACE prod;
DEFINE DATABASE orders;
USE DATABASE orders;
DEFINE COLLECTION notes;
CREATE notes = { body: 'before there were users' };
DEFINE USER ada ON prod.orders ROLE editor PASSWORD 'correct horse';

From the statement after that one, an anonymous session is refused — and for reads as well as writes:

SELECT * FROM notes;

Refused — NotSignedIn. So is a write, so is declaring another user, and so is dropping the one that exists:

DROP USER ada;

NotSignedIn. There is no back door, deliberately: a store cannot be re-opened from outside by removing its last account. The consequence is worth knowing before you need it — a lost owner password is a restore from backup, not a recovery. See Users.

Signing in

$ TESSARIDB_PASSWORD='correct horse' tessaridb --at 127.0.0.1:7654 --user ada

The password comes from the environment and there is no flag that takes one. That is not a convenience: an argument is in the process table, where any user on the machine can read it with ps, and a password that has been in a process table is a password that has been published.

What the session remembers

A connection is a session and not a single round trip. Two things live in it:

Both are gone when the connection closes, which is why a reconnecting client re-sends its USE statements. A pool of connections that assumes otherwise will work until the first reconnect and then read from the wrong database.

Next

• Users and access — roles, scope, and what a grant narrows.
• Running a node — health, metrics, and stopping one properly.
• Clients — reaching a node from a program rather than a prompt.