aboutsummaryrefslogtreecommitdiffstats
path: root/ARCHITECTURE.md
diff options
context:
space:
mode:
authorJan Tuomi <jan@jantuomi.fi>2025-05-02 16:37:29 +0300
committerJan Tuomi <jan@jantuomi.fi>2025-05-02 16:37:29 +0300
commitef72b74ec34e95a38890d542cda298dd6565d5ad (patch)
tree63fe96b24a8534e8dd2d88b1ca3d69b21c502d3e /ARCHITECTURE.md
parentdaca0e6b68d32d885face00d68df5b5cb00e098b (diff)
Start replacing browser with a chat demo
Diffstat (limited to 'ARCHITECTURE.md')
-rw-r--r--ARCHITECTURE.md8
1 files changed, 1 insertions, 7 deletions
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
index a34330a..bf622e7 100644
--- a/ARCHITECTURE.md
+++ b/ARCHITECTURE.md
@@ -381,10 +381,4 @@ When the active segment changes, the process should reopen the files between the
The schema handling up to now has been in a weird spot: the DB requires a schema, i.e. a mapping from fields (types with bound `F: Eq`) to database types (`Type`), but does not persist this information anywhere. Every initialization of the DB might have a different view of the schema. This is fine if the readers are all instances of a single piece software, but if the DB is accessed by multiple different applications, the schema must be somehow communicated between them out-of-band. This is not ideal, of course.
-I tried removing the schema completely. All validation is outsourced to the user. This works, but has even more quirks, mostly stemming from the fact that now the database has no idea what the data is supposed to look like.
-
-I started implementing a database browser application for demoing purposes, and realized that the schema must be persisted in some way, since otherwise the browser app would have to either 1) infer the schema from the data, or 2) require the user to input the schema somehow. Both of these are kind of unsuitable for the feel I'm going for with this project.
-
-My current idea is to store the schema in a file in the data directory upon first initialization. The schema file contains a mapping from field names to types. The schema file is read upon DB initialization and used to validate the data.
-
-The user can change the schema only by adding new nullable fields. This is the only schema evolution action that is both backwards and forwards compatible, which is a nice property to have. Adding nullability to an existing field is backwards compatible, but not forwards compatible. The compatibility mode (BACKWARDS, FULL) might be a good thing to expose to the user.
+I removed the schema completely. All validation is outsourced to the user. This works, but has some quirks, mostly stemming from the fact that now the database has no idea what the data is supposed to look like.