DataMind Oda keeps its own records on your computer: workspace records and the extra details attached to individual chats. This page is the reference for the storage layer behind those records: its parts, the two stores it can use, what every write guarantees, and its limits. Your own files are not part of this storage (see Workspaces, files and permissions), and chat logs and saved credentials have stores of their own (Chat logs on disk, Stored credentials).
Records are grouped into units: one unit is one named set of records kept by one backend. Within a unit, records sit in tables, and the unit can also keep single global values that are not tied to a record.
This storage is Oda's own bookkeeping. It adds nothing to a model request, and no part of it is shown to the model.
The file store keeps each unit as files under one folder, in plain, formatted JSON that a person can read.
The database store keeps every unit in one SQLite database file.
| Choice | What it decides | Default and limits |
|---|---|---|
| File store folder | Where the JSON files live. | No default; chosen at setup and created when first needed. |
| Database path | Which SQLite database holds the records. | One file path, or an in-memory database that lasts only while the program runs. |
| Journal mode | How the database keeps its journal while it works. | wal by default; delete, truncate or persist on filesystems where the shared files wal needs do not work, such as some network mounts; memory and off are refused. |
| Backend per domain | Which store keeps a given domain. | One backend is the default for domains that do not choose; a domain can be routed to a different backend. |
Names follow strict patterns: a unit or table name starts with a lowercase letter and continues with lowercase letters, digits and underscores; a record key uses letters, digits, hyphens and underscores. A name outside its pattern is refused before anything is written.
When something is wrong with the storage's setup or its stored data, the failure names the problem instead of staying silent. Examples:
storage backend '<name>' is already registered: two parts claimed the same backend name, so the second claim is refused instead of being accepted.storage backend '<name>' is not registered (registered: <names|none>): something asked for a backend that is not part of the setup; the last part lists the registered names, or none.storage form '<form>' is not mounted: a form is one way of using a backend; something asked for one that this setup does not provide.domain '<name>' is already open: the same domain was opened twice, which the storage refuses; only one handle at a time is allowed.domain '<domain>': stored <slot> does not match its schema: a stored value does not match the shape the reader expects; the slot names the record or the global value that failed.Oda's own records: its workspace list and the details it keeps about individual chats, so they survive a restart. Your own files are not part of it; they stay in the folders you gave Oda, as described in Workspaces, files and permissions.
No. Nothing in it is shown to the model, and it adds nothing to a model request. It is Oda's own bookkeeping, kept apart from the content of a chat.
The folder for the file store is chosen when DataMind Oda is set up. There is no default and Oda never guesses one; it creates the folder when it first needs it.
It depends on the unit's layout. In the record-per-document layout, the damaged document reads as an absent record and the rest of the unit still opens. In the whole-unit layout, the file refuses to open and its stored data is left untouched.
No. A database stamped with a layout version other than the current one is refused outright; this format has no migrations. The file store follows the same idea: a document whose version is not accepted is not migrated, it reads as an absent record.
Nothing changes. The store keeps its last committed state, the in-memory copy is not updated, and no change is announced, so a rejected write never rides along with a later one.
A unit has exactly one writer and one live handle at a time, so two writers cannot overwrite each other's records. A second attempt to open the same unit is refused.
Plainly, no. Oda creates its folders and files so that only your user account can use them, but if another user can replace a stored file or the database, nothing here detects or prevents that.
Each domain names its backend. One backend is the default for domains that do not choose, and a domain can be routed to a different backend, so records can live in different stores side by side.
wal, the default, suits local disks. On filesystems where the shared files wal needs do not work, such as some network mounts, use a rollback mode: delete, truncate or persist. memory and off are refused, because they would drop the durability every write promises.