Interface

The method [Database]::run (or alternatively Database::run_timed) is called to execute an SQL query. This takes a [Query] parameter which accumulates SELECT results and which also has methods for accessing the environment and controlling output. Custom builtin functions implement [CExp] and have access to the query via an [EvalEnv] parameter, which can be downcast if ncessary.

Examples

use rustdb::{Database, SharedPagedData, SimpleFileStorage, WebQuery, INITSQL};
use std::net::TcpListener;
use std::sync::Arc;

let sfs = Box::new(SimpleFileStorage::new(
"c:\\Users\\pc\\rust\\sftest01.rustdb",
));
let spd = Arc::new(SharedPagedData::new(sfs));
let apd = spd.open_write();
let db = Database::new(apd, INITSQL);

let listener = TcpListener::bind("127.0.0.1:3000").unwrap();
for tcps in listener.incoming() {
if let Ok(mut tcps) = tcps {
if let Ok(mut wq) = WebQuery::new(&tcps) {
// wq.trace();
let sql = "EXEC web.Main()";
// Execute SQL. http response, SQL output, (status,headers,content) is accumulated in wq.
db.run_timed(&sql, &mut wq);
// Write the http response to the TCP stream.
let _err = wq.write(&mut tcps);
// Save database changes to disk.
db.save();
}
}
}

See here for more advanced example (Axum webserver with ARGON hash function).

Features

This crate supports two cargo features.

• builtin : Allows extra SQL builtin functions to be defined.
• max : Exposes maximal interface, including all internal modules (default).

General Design of Database

SortedFile stores fixed size Records in a tree of Pages. SortedFile is used to implement:

• Variable length values ( which are split into fragments - see bytes module - although up to 15 bytes can be stored directly. ).

• Database Table storage. Each record has a 64-bit Id.

• Index storage ( an index record refers back to the main table ).

Pages have a maximum size, and are stored in CompactFile, which stores logical pages in smaller regions of backing storage.

When a page becomes too big, it is split into two pages.

Each page is implemented as a binary tree ( so there is a tree of trees ).

ToDo List

Implement DROP INDEX, ALTER TABLE, fully implement CREATE INDEX.

Consider replication/backup/durability issues Here

Have a replication server. Replication server has old copy of database, and log. Changes are sent to replication server, which adds changes to the log. At some point the old copy can be updated ( and the history is lost ). Replication server could be set to run 1 week behind.
Can set up extra replication servers from primary replication server. During cloning process, the replication server stops applying updates. Database at a paticular point in time can be recreated by running replication log forwards. Question is WHAT to sent to replication server? Seems logical to send update messages ( SQL strings and environment values ).

Sort out error handling for PARSEINT etc.

Work on improving/testing SQL code, browse schema, float I/O. Login.