Use Example: Settings Read by Key and Audited With SQL

Feature flags and settings are read all the time and listed rarely. The code asks “is the new checkout on?” on every request. Once in a while a person asks “what are all the search settings right now?” A plain keyspace in KvSQL answers both, with no schema at all.

Write settings as keys and values:

let mut tx = db.begin_write()?;
tx.put("settings", b"checkout.new_flow", b"on")?;
tx.put("settings", b"search.fuzzy", b"off")?;
tx.put("settings", b"search.limit", b"50")?;
tx.put("settings", b"upload.max_mb", b"20")?;
tx.commit()?;

Read one by key, straight from storage:

let on = db.get("settings", b"checkout.new_flow")? == Some(b"on".to_vec());

And look at them through SQL. A keyspace with no table definition shows up as a table with two BLOB columns, key and value, so a cast turns them into text:

SELECT CAST(key AS TEXT), CAST(value AS TEXT) FROM settings
 WHERE CAST(key AS TEXT) LIKE 'search.%' ORDER BY 1;

In the project’s use example program, the key read gave on, and the query listed search.fuzzy = off and search.limit = 50. The output is in case-studies.md.

The same works over HTTP with kvsqld. PUT /kv/settings/search.limit writes a value, GET /kv/settings/search.limit reads it, and POST /sql runs the audit query. When the list of settings grows into something with structure, turn it into a real table. The key door works the same on tables, through get_row.