Closed drexlma closed 11 months ago
Thanks for the PR.
1) Without a migration function that installs the new schema and alters existing schema, this will break existing installations.
2) Isn't it better to have a JSON field (eg: forwarded_meta
) alongside the message rather than creating a new table and linking it? The forwarded details are always 1:1, right?
@1: oh no, you're right of course. Do you have any suggestion? We don't have a schema version here yet.
@2: it would have been an option. But I decided against it. I'm not a fan of JSON in a table field. I also need a table for future tasks. In json I can't form a sum or count using SQL.
1) We can have an implicit version check that executes an idempotent migration. This should also be printed in stdout because large databases might take time to be altered.
2) I'm not a fan of unnecessary de-normalisation, but here, it seems that having a JSON metadata field (or even a couple of additional fields) may be meaningful. The forwarded meta record is immutable, corresponds 1:1 to a specific message, and has no other relationships. The simple JSON metadata blob here can be queried and doesn't seem to have any fields that would meaningfully need a COUNT(). For a simple program such as tgarchive, it seems complicated to have a table which stores 1:1 records that introduce a JOIN.
Add forwarded from to the database Step 1 for #89