# Storage layer for Notesmachine This library implements the core functionality of Notesmachine and describes that functionality to a storage layer. There's a bit of intermingling in here which can't be helped, although it may make sense in the future to separate the decomposition of the note content into a higher layer. Notesmachine storage notes consist of two items: Zettle and Kasten, which are German for "Note" and "Box". Here are the basic rules: - Boxes have titles (and date metadata) - Notes have content and a type (and date metadata) - Notes are stored in boxes - Notes are positioned with respect to other notes. - There are two positions: - Siblings, creating lists - Children, creating trees like this one - Notes may have references (pointers) to other boxes - Notes may be moved around - Notes may be deleted - Boxes may be deleted - When a box is renamed, every reference to that box is auto-edited to reflect the change. If a box is renamed to match an existing box, the notes in both boxes are merged. Note-to-note relationships form trees, and are kept in a SQL database of (`parent_id`, `child_id`, `position`, `relationship_type`). The `position` is a monotonic index on the parent (that is, every pair (`parent_id`, `position`) must be unique). The `relationship_type` is an enum and can specify that the relationship is *original*, *embedding*, or *referencing*. An embedded or referenced note may be read/write or read-only with respect to the original, but there is only one original note at any time. Note-to-box relationships form a graph, and are kept in the SQL database as a collection of *edges* from the note to the box (and naturally vice-versa). - Decision: When an original note is deleted, do all references and embeddings also get deleted, or is the oldest one elevated to be a new "original"? Or is that something the user may choose? - Decision: Should the merging issue be handled at this layer, or would it make sense to move this to a higher layer, and only provide the hooks for it here?