Garner (as in, a place where things are kept; a store or silo) is a GPLv3 distributed,
asynchronous, reactive key-value store implemented in C++11 as a library. It can be used in a variety of ways. The simplest
way would be a simple database. However, garner can store both chunks of data (referred to as bales) and routines
which act on data (querns).
The primary novelty of Garner is that when bales (i.e., data) is altered, querns (i.e., user-specified routines) that depend on the data are re-executed. This allows one to automatically handle complex data dependencies for hierarchies of data.
Garner is part of the DICOMautomaton software collection. It can be used for general purpose work but is written specifically for assisting in research in medical physics and, especially, radiotherapy dose-volume analyses.
Garner was designed to be distributed, reactive, and lazy. Asynchronicity and concurrency are utilized heavily - Garner is designed to be run on multiple machines and multiple cores in a single machine. But the interface doesn't expose this. Rather, the interface should be familiar if you've ever used a key-value store. Fundamentally, bales represent a value (either a static value like a string, or a routine for computing a value on demand) and a std::string is used as the key.
Garner fills a niche somewhere between SQL databases, modern key-value stores, and large distributed computing infrastructure like map-reduce. The ability to manage dependencies and store querns sets Garner apart. Note that while querns are somewhat similar to SQL's stored procedures and user-defined functions, they differ in that bales are "backed" by querns and will automatically be regenerated afresh if dependencies have changed (depending on the specified laziness). (Querns are sort of like SQL stored procedures which are confined to a single record and communicate through that record's value.)
Q. Why not use other (more mature, more comprehensive, better tested) databases?
A. Garner was written to scratch an itch. Starting from scratch provided lots of opportunity to try out-of-the-ordinary designs, and the ability to simply throw out the parts that didn't work instead of trying to work around limitations in existing implementations.
Q. What is the best way to use libGarner?
A. As a key-value store. If you have routines that depend on the latest, freshest data in the database, consider writing a quern and letting Garner worry about keeping it up to date.
Q. How do I contribute?
Q. Where do I send bug reports?
Q. How do I contact the author?
A. Please send all thoughts, patches, suggestions, and notes to .
There are no current plans to release this project. Please enquire via for access. Note that PostgreSQL coupled with some sort of application-level controller can accomplish many (currently not all) of the goals of this project. Recent releases (e.g., 9.4-9.6, circa 2015-2016) bring needed features like row-level access control and improved support for replication and workload distribution that make continued work on Garner less compelling.