Part of #18
Question
How do new capability columns reach databases that already exist?
init_db is Base.metadata.create_all (shared/db.py:35): it creates missing tables but never alters existing ones. There is no Alembic and no migration tooling in pyproject.toml. So adding a column to accounts leaves any existing mailchat.db silently missing it, and queries fail at runtime.
Settle: does this project adopt a migration tool now, hand-roll an idempotent ALTER TABLE check at startup, or accept "delete your database and reconnect" as the policy while pre-MVP? Note that deleting the DB is currently cheap — accounts re-verify on connect — but stops being cheap once messages accumulate locally.
Whatever is chosen becomes the precedent for every later schema change, including the several that Group messages into person+subject conversations and Reply within a conversation already imply.
Part of #18
Question
How do new capability columns reach databases that already exist?
init_dbisBase.metadata.create_all(shared/db.py:35): it creates missing tables but never alters existing ones. There is no Alembic and no migration tooling inpyproject.toml. So adding a column toaccountsleaves any existingmailchat.dbsilently missing it, and queries fail at runtime.Settle: does this project adopt a migration tool now, hand-roll an idempotent
ALTER TABLEcheck at startup, or accept "delete your database and reconnect" as the policy while pre-MVP? Note that deleting the DB is currently cheap — accounts re-verify on connect — but stops being cheap once messages accumulate locally.Whatever is chosen becomes the precedent for every later schema change, including the several that Group messages into person+subject conversations and Reply within a conversation already imply.