Schema
Fhirbase schema is regular and uniform. Each resource is saved in a table with the lower case name of the resourceType. For example, the Patient resource is saved in the patient table. All resource tables has similar structure:
1
CREATE TABLE "patient" (
2
id text PRIMARY KEY, // id of resource
3
txid bigint not null, // version id and logical transaction id
4
ts timestamptz DEFAULT NOW(), // last updated time
5
resource_type text, // resource type
6
status resource_status not null, // resource status
7
resource jsonb not null // resource body
8
);
Copied!
idis an resource IDtxidis the versionId for the resource and at the same time the sequential id of logical transaction, which can be used for implementing integrations, ETags, reactive APIs, etc.tsstores a timestamp of last resource updatestatusis enumeration with possible values:create,updated,deleted,recreated
Previous versions of resources are saved in the history table:
1
CREATE TABLE "patient_history" (
2
id text,
3
txid bigint not null,
4
ts timestamptz DEFAULT current_timestamp,
5
resource_type text default 'Media',
6
status resource_status not null,
7
resource jsonb not null,
8
PRIMARY KEY (id, txid)
9
);
Copied!
History tables are postfixed with "_history" and have same structure as primary tables. On resource update Fhirbase moves the current version of the resource from the primary table to the history table.
Sometimes you change many resources in one transaction and/or want to store meta-information about transactions. Fhirbase has a special transaction table to store transaction info and the
id sequence for transaction is used as versionId (txid) in resources, which were touched in this transaction.1
CREATE TABLE "transaction" (
2
id serial primary key,
3
ts timestamptz DEFAULT current_timestamp,
4
resource jsonb
5
);
Copied!
The schematic transaction workflow usually looks like this:
- Create a new record in the transaction table or get next transaction ID from transaction ID sequence -
txid - For all resources which will be changed in the transaction, set
txidto the value obtained in previous step - Save changed resources
txid and record in transaction table can be used to track back changes. txid can also be used as the globally increasing version id for resources - a logical clock which may be helpful for caches and reactive engines implementation.
Last modified 3yr ago
Copy link