Kolonnerne, ikke flytningen. Gmail-handlerne læser stadig user_settings, og en migration, der tømte den tabel før de var skrevet om, ville koble en fungerende postkasse fra. Det additive først; flytningen når koden på den anden side er klar til den, og den ligger som PENDING_gmail_move.sql.txt uden for .sql-mønstret, så den ikke kan køre ved et uheld. Udløseren fik sin egen kolonne frem for at blive pakket ind i label med et kolon. En kolonne, der rummer to ting adskilt af et tegn, er en kolonne, nogen læser forkert senere — og en etiket med kolon i navnet ville gøre det på første dag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
49 lines
2.1 KiB
Plaintext
49 lines
2.1 KiB
Plaintext
-- NOT A MIGRATION YET. Deliberately outside the .sql glob so it cannot run.
|
|
--
|
|
-- This is the data move for task #23. It must not be applied until the Gmail
|
|
-- handlers read the mailboxes table instead of user_settings: it empties the
|
|
-- settings row, and running it early would disconnect a working mailbox.
|
|
--
|
|
-- Rename to 0016_gmail_is_a_mailbox.sql when internal/httpapi/gmail_handlers.go
|
|
-- has been rewritten.
|
|
|
|
-- The values move across still sealed. Both tables seal with the same key and
|
|
-- store the same string, so copying the ciphertext verbatim is not a shortcut
|
|
-- around the encryption — it is the encryption, untouched. That also means this
|
|
-- migration does not need the key, which a migration has no business holding.
|
|
--
|
|
-- `username` is the address the account reports, and it is what makes the unique
|
|
-- index meaningful. It may be empty on rows that never got that far; two such rows
|
|
-- cannot exist for one person anyway, because the settings table could only hold
|
|
-- one.
|
|
INSERT INTO mailboxes (
|
|
id, user_id, kind, name, host, username, password, folder,
|
|
refresh_token, access_token, expires_at, label, trigger_kind, seen,
|
|
last_uid, last_sync_at, created_at
|
|
)
|
|
SELECT
|
|
lower(hex(randomblob(16))),
|
|
s.user_id,
|
|
'gmail',
|
|
COALESCE(json_extract(s.values_json, '$.email'), 'Gmail'),
|
|
'',
|
|
COALESCE(json_extract(s.values_json, '$.email'), ''),
|
|
'',
|
|
'INBOX',
|
|
COALESCE(json_extract(s.values_json, '$.refresh_token'), ''),
|
|
COALESCE(json_extract(s.values_json, '$.access_token'), ''),
|
|
COALESCE(json_extract(s.values_json, '$.expires_at'), 0),
|
|
COALESCE(json_extract(s.values_json, '$.label'), ''),
|
|
COALESCE(json_extract(s.values_json, '$.trigger'), 'starred'),
|
|
COALESCE(json_extract(s.values_json, '$.seen'), '[]'),
|
|
0,
|
|
0,
|
|
unixepoch()
|
|
FROM user_settings s
|
|
WHERE s.scope = 'gmail'
|
|
AND COALESCE(json_extract(s.values_json, '$.refresh_token'), '') <> '';
|
|
|
|
-- Emptied, not deleted: the row may hold nothing else today, but the table is
|
|
-- shared and a DELETE here would be a habit worth not forming.
|
|
UPDATE user_settings SET values_json = '{}' WHERE scope = 'gmail';
|