docs: add SQL schema documentation - #8493
Conversation
8e4c7f3 to
4e7ee48
Compare
|
Quite like it. I didn't review the comments except in passing (maybe @r10s is also a review authority to reckon with there :), but did a PR #8514 to make the schema become tested in CI. I wonder if we could evolve to introduce an env |
8bafac5 to
7ac86fc
Compare
5d396e1 to
e89e8b2
Compare
e89e8b2 to
2f032d3
Compare
| -- For incoming messages, SELF (1). | ||
| -- For outgoing messages, ID of the first recipient. | ||
| -- TODO: it is not useful in group chats, can it be deprecated? | ||
| to_id INTEGER DEFAULT 0, |
There was a problem hiding this comment.
-
for groups
to_idis 0 - so it seems not to be needed to really deliver messages. -
to_idis used to check for "system messages" asto_id == ContactId::INFO- but at a first glance only in combination withfrom_id == ContactId::INFO- which also makes more sense.
apart from that, i do not know about where it is used in business logic - only that it is set and passed around like crazy :) but maybe i have overseen smth
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
It turned out to be impossible to get rid of to_id for webxdc info messages, they have from_id of the sender and to_id of INFO. from_id is then used to collapse messages by the same author, and to_id is used to trigger displaying the message as an info message.
to_id is used to check for "system messages" as to_id == ContactId::INFO - but at a first glance only in combination with from_id == ContactId::INFO - which also makes more sense.
In all places i have seen the condition is to_id == ContactId::INFO || from_id == ContactId::Info. add_info_msg_with_cmd creates messages with info to_id, but optionally different from_id.
I documented the webxdc usecase instead of trying to get rid of to_id. It is probably possible to still cleanup other usage where to_id is set to the first recipient and document that only values 0 and 2 should be written and this is essentially an info marker. Otherwise all this to_id management makes it look like the first recipient is somehow important, but it is actually not used for anything.
2f032d3 to
62e27c9
Compare
86c762e to
d4beb82
Compare
83e88fc to
8819296
Compare
54ddfd4 to
5034f45
Compare
hpk42
left a comment
hpk42
left a comment
There was a problem hiding this comment.
looks good to me, just a few nits. definitely a nice improvement.
|
|
||
| def normalize(stmt): | ||
| stmt = re.sub(r"\s+", " ", stmt).strip() | ||
| stmt = stmt.replace("CREATE TABLE IF NOT EXISTS ", "CREATE TABLE ") |
There was a problem hiding this comment.
i think this better should handle all "IF NOT EXISTS" forms.
| stmt = stmt.replace("CREATE TABLE IF NOT EXISTS ", "CREATE TABLE ") | |
| stmt = re.sub(r"^(CREATE (?:UNIQUE )?(?:TABLE|INDEX|VIEW|TRIGGER)) IF NOT EXISTS ", r"\1 ", stmt) |
There was a problem hiding this comment.
Left it as is, we will notice when this breaks if some migration adds new syntax. It's unlikely we will add views or triggers. Unique index maybe, but then the script can be tweaked as needed.
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. Co-Authored-By: bi酶rn <r10s@b44t.com>
finds things like "exists in the db, but is not documented" or "documented but not in the db".
5034f45 to
ff750e2
Compare
4 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.