nhweston
commented
3 years ago I will outline what I intend for a V1.
Scope
- Only SQLite will be supported.
- A command-line argument corresponds to a single table in a database.
- The only capability method available will return all rows from that table.
Programming with database capabilities
Programmers intending to accept a database table must provide its table definition in the form of a record type. Each field of the record type corresponds to a column of that table.
For a table definition to be valid, all fields must be of type String. All column values returned from the database will be converted to strings. (Note that NULL will be converted the empty string.) In the future, we will allow other types to be used. A preruntime check will ensure that the table definition is compatible with the actual database table. Table definitions may omit columns that are present in the table, but they may not include columns that are not present.
As an example, the following is a valid table definition:
type Student = {
id : String,
name : String,
wam : String
}…and is compatible with a table with the following SQL definition:
CREATE TABLE student (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
gpa DECIMAL(3, 2),
wam INTEGER
);(Note that the table definition omits the gpa column.)
Unlike all capabilities that exist in Cooma so far, there is a capability type constructor for databases, defined as:
type Table = fun (A : Type) {
all : () Vector(A)
}Note that A must be a valid table definition, and this will be enforced at compile time. (However, its compatibility with a database table can only be checked at preruntime.)
Table::all, when applied, will return all rows of the table.
Here is an example of a simple program that returns all rows from a table:
fun (students : Table(Student)) students.all()There is a problem with parameterised capability types evident in this example that will need to be addressed – Where is the Student type defined? Currently, a function expression must be at the top-level to be treated as the program itself, but this leaves no room for definitions that a programmer may want to use in the types of program arguments.
Of course, the programmer could do something like this:
fun (students : Table({
id : String,
name : String,
wam : String
})) students.all()…but this is certainly not ideal.
Command-line arguments
SQLite databases are stored as files, so command-line arguments can simply provide a path to the file, followed by the table. For example:
run -r program.cooma ./database.db:studentBefore execution, Cooma will check that the database and table exist, and that the table definition is compatible.
Implementation
Primitives.scala is becoming quite long and I think it is appropriate to place file, HTTP, and database capabilities into separate files.
A challenge in implementing database capabilities is managing the connection, which is essentially state. The connection needs to be opened during the preruntime phase to check the compatibility of the table definition. The same connection should persist and be reused until the program exits. This breaks the current assumption that capabilities are essentially stateless functions. The easiest solution would be to have the database connection form mutable state within Primitives.
The Java SQL library is sufficient for our purposes. Table definition compatibility can be checked using the SQLite table_info pragma.
inkytonik
The plan is to add command-line capabilities for access to databases. This will require an analysis of the kinds of capability we need (e.g., read, update, maybe fine-grained to tables or parts of tables) and thinking about suitable database targets.
We should also think about the interaction between the database capabilities and the others. E.g., can we use this approach to ensure that db info can't be written to a file, for example. Is that a kind fo restricted capability that the user can grant?
The aim is to investigate and demonstrate how the Cooma approach can help to avoid some of the issues that arise in database applications such as web sites. E.g., the accidental reveal of secret information.