On one extreme, schemas are a waterfall top-down
On the other extreme, content is what it is, and the schema is implied based on what is literally there.
In the middle, you may also have data that defines its own schema. But there is no enforcement that it matches the parent schema above, or the literal data below.
This is especially apparent during schema migrations, and concurrency race conditions. It is possible for data to be in a partially-migrated state.
Modes of Schema
No Schema - Raw Data that must be read and edited
Self-Defined Schema - A resource/doc or a blob will self-declare a schema
Define Schema for children and/or grandchildren
Its possible that a schema (or parent schema) conflicts with reality, this is not great but we must handle it elegantly. In some cases, we should allow the conflict.
Should schemas be editable, and if so, how? Or, is it okay that they are immutable? When editing a schema, do we need to handle concurrency and CRDTs, or is that a liability?
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime