2.0 KiB
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?