docs: add SQL schema documentation - #8493
Conversation
| starred INTEGER DEFAULT 0, | ||
| timestamp_sent INTEGER DEFAULT 0, -- Timestamp of the message as sent in the Date header. | ||
| timestamp_rcvd INTEGER DEFAULT 0, | ||
| hidden INTEGER DEFAULT 0, |
There was a problem hiding this comment.
This is a bad column, needs a good documentation.
In many cases the message should be trashed instead of hiding. Hiding is used for rare cases when you want the message to be "in the chat" so they are marked as seen. One is reactions, but there was something else, i think location streaming. Would be great to deprecate it somehow or at least discourage more usage of it. The problem with such hidden messages is that it is unclear when they are supposed to be cleaned up and they likely slow down chat loading if you have lots of reactions in the chat.
| mime_compressed INTEGER NOT NULL DEFAULT 0, | ||
| txt_normalized TEXT, | ||
| deleted INTEGER NOT NULL DEFAULT 0, | ||
| pre_rfc724_mid TEXT DEFAULT '' |
There was a problem hiding this comment.
This should be grouped with rfc724_mid and also needs a very good documentation, it is always difficult to remember what goes into rfc724_mid when only a pre-message is received.
| -- Commented SQLite database schema. | ||
| -- | ||
| -- This file should only be used for documentation, | ||
| -- do not run this SQL e.g. to create databases. |
There was a problem hiding this comment.
| -- do not run this SQL e.g. to create databases. | |
| -- do not run this SQL e.g. to create databases. | |
| -- This is because we want to be 100% sure | |
| -- that new users and users who run the migrations | |
| -- get the same database schema. |
| CREATE INDEX tls_spki_index_timestamp ON tls_spki (timestamp); | ||
|
|
||
| -- | ||
| -- Deprecated tables. |
There was a problem hiding this comment.
| -- Deprecated tables. | |
| -- Deprecated and unused tables. | |
| -- We don't immediately drop unused tables, | |
| -- because we want users to be able to downgrade. |
I think none of them are used anymore?
There was a problem hiding this comment.
Yes, I think we can even make a migration to finally drop all of them.
There is currently no place to document up to date SQL schema. New database is initialized with src/sql/tables.sql and then updated by migrations, So tracking down how some column is used requires grepping the code, looking for a migration adding it and corresponding commits. The documentation is frozen at version 160. Ideally it should be updated when adding a migration, but most of the value is documenting old stable tables. There was an idea to automatically check if the documentation corresponds to the database schema, but there is no tool to compare the schema. SQLite itself stores database schema as the text in the schema table, with columns appended later without any formatting. Even SQLite REPL which has ".schema --indent" option does not handle the comments properly and produces invalid SQL with closing parenthesis commented out.
8e4c7f3 to
4e7ee48
Compare
2 participants
There is currently no place to document up to date SQL schema. New database is initialized with src/sql/tables.sql and then updated by migrations,
So tracking down how some column is used requires grepping the code, looking for a migration adding it and corresponding commits.
The documentation is frozen at version 160.
Ideally it should be updated when adding a migration, but most of the value is documenting old stable tables.
There was an idea to automatically check
if the documentation corresponds to the database schema, but there is no tool to compare the schema.
SQLite itself stores database schema as the text
in the schema table, with columns appended later
without any formatting.
Even SQLite REPL which has ".schema --indent" option does not handle the comments properly
and produces invalid SQL
with closing parenthesis commented out.