Using SQL databases
To connect Atmo with your SQL database, you will define the connection using the connections section of the Directive, and then define queries that your Runnables can execute. Runnables are not allowed to execute arbitrary queries. Instead, a list of named queries are provided in a Queries.yaml file, and then your Runnables are allowed to execute them.
If you haven't already, take a look at Connections to define the connection to your database, then come back here.
Atmo's Database capability is in preview, and we would love your feedback on the approach as well as the Rust APIs. We are eager to improve it, and we hope you'll try it out! Please join our Discord to give us feedback.

Defining queries

Once the connection to your database is defined, create a Queries.yaml file in your project's directory, right next to Directive.yaml. It will have this structure:
1
queries:
2
- name: "InsertUser"
3
query: |-
4
INSERT INTO users (uuid, email, created_at, state, identifier)
5
VALUES ($1, $2, NOW(), 'A', 12345)
6
7
- name: "SelectUserWithUUID"
8
query: |-
9
SELECT * FROM users
10
WHERE uuid = $1
11
12
- name: "UpdateUserWithUUID"
13
query: |-
14
UPDATE users SET state='B'
15
WHERE uuid = $1
Copied!
You can define any number of queries. Each query must have a name and a query value.
Queries can optionally have a type field (specifying select | update | insert | delete) and a varCount field to specify the number of variables in the query. In most circumstances, these optional fields are detected automatically by Atmo, but if for any reason they are detected incorrectly, you can set them explicitly.

Query variables

Queries can contain variables in either the MySQL style ? or in the PostgreSQL style $1. Both will be auto-detected by Atmo, and Runnables will be required to provide the correct number of arguments to fill those variables whenever a query is called.

How it works

SQL queries in Atmo are automatically turned into prepared statements that ensure your queries are executed safely. Atmo uses industry-standard database drivers to maintain a connection pool with your database. Runnables are allowed to execute the defined queries and provide the arguments to be inserted into those queries. Your code does not need to concern itself with the underlying database connections, pooling, credentials, etc. You can focus on building your business logic.

Executing queries

Once you've defined queries in your Queries.yaml file, the suborbital Rust crate has APIs for executing various query types:
1
use suborbital::runnable::*;
2
use suborbital::db;
3
use suborbital::db::query;
4
use suborbital::log;
5
use uuid::Uuid;
6
7
struct CreateUser{}
8
9
impl Runnable for CreateUser {
10
fn run(&self, _: Vec<u8>) -> Result<Vec<u8>, RunErr> {
11
let uuid = Uuid::new_v4().to_string();
12
13
let mut args: Vec<query::QueryArg> = Vec::new();
14
args.push(query::QueryArg::new("uuid", uuid.as_str()));
15
args.push(query::QueryArg::new("email", "[email protected]"));
16
17
match db::insert("InsertUser", args) {
18
Ok(_) => log::info("insert successful"),
19
Err(e) => {
20
return Err(RunErr::new(500, e.message.as_str()))
21
}
22
};
23
24
let mut args2: Vec<query::QueryArg> = Vec::new();
25
args2.push(query::QueryArg::new("uuid", uuid.as_str()));
26
27
match db::update("UpdateUserWithUUID", args2.clone()) {
28
Ok(_) => log::info("update successful"),
29
Err(e) => {
30
return Err(RunErr::new(500, e.message.as_str()))
31
}
32
};
33
34
match db::select("SelectUserWithUUID", args2) {
35
Ok(result) => Ok(result),
36
Err(e) => {
37
Err(RunErr::new(500, e.message.as_str()))
38
}
39
}
40
}
41
}
42
43
// initialize the runner, do not edit below //
44
static RUNNABLE: &CreateUser = &CreateUser{};
45
46
#[no_mangle]
47
pub extern fn _start() {
48
use_runnable(RUNNABLE);
49
}
Copied!
Runnables can execute any of the queries defined in Queries.yaml. The args they provide are inserted into the queries' variables by Atmo, and then executed. The query's results are returned to the Runnable in JSON form.
Last modified 10d ago