This guide explains how to make database schema changes in MeshView using Alembic migrations.
When you need to add, modify, or remove columns from database tables, you must:
- Update the SQLAlchemy model
- Create an Alembic migration
- Let the system automatically apply the migration
Edit meshview/models.py to add/modify the column in the appropriate model class:
class Traceroute(Base):
__tablename__ = "traceroute"
id: Mapped[int] = mapped_column(primary_key=True, autoincrement=True)
# ... existing columns ...
route_return: Mapped[bytes] = mapped_column(nullable=True) # New columnGenerate a new migration file with a descriptive message:
./env/bin/alembic revision -m "add route_return to traceroute"This creates a new file in alembic/versions/ with a unique revision ID.
Edit the generated migration file to implement the actual database changes:
def upgrade() -> None:
# Add route_return column to traceroute table
with op.batch_alter_table('traceroute', schema=None) as batch_op:
batch_op.add_column(sa.Column('route_return', sa.LargeBinary(), nullable=True))
def downgrade() -> None:
# Remove route_return column from traceroute table
with op.batch_alter_table('traceroute', schema=None) as batch_op:
batch_op.drop_column('route_return')When you restart the application with mvrun.py:
- The writer process (
startdb.py) starts up - It checks if the database schema is up to date
- If new migrations are pending, it runs them automatically
- The reader process (web server) waits for migrations to complete before starting
No manual migration command is needed - the application handles this automatically on startup.
Add both files to git:
git add meshview/models.py
git add alembic/versions/ac311b3782a1_add_route_return_to_traceroute.py
git commit -m "Add route_return column to traceroute table"Always use batch_alter_table for SQLite compatibility:
with op.batch_alter_table('table_name', schema=None) as batch_op:
batch_op.add_column(...)SQLite has limited ALTER TABLE support, and batch_alter_table works around these limitations.
- Writer process (
startdb.py): Runs migrations on startup - Reader process (web server in
main.py): Waits for migrations to complete - Migrations are checked and applied every time the application starts
- The system uses a migration status table to coordinate between processes
# Integer
column: Mapped[int] = mapped_column(BigInteger, nullable=True)
# String
column: Mapped[str] = mapped_column(nullable=True)
# Bytes/Binary
column: Mapped[bytes] = mapped_column(nullable=True)
# DateTime
column: Mapped[datetime] = mapped_column(nullable=True)
# Boolean
column: Mapped[bool] = mapped_column(nullable=True)
# Float
column: Mapped[float] = mapped_column(nullable=True)Migrations are stored in: alembic/versions/
Each migration file includes:
- Revision ID (unique identifier)
- Down revision (previous migration in chain)
- Create date
upgrade()function (applies changes)downgrade()function (reverts changes)
If migrations don't run automatically:
- Check that the database is writable
- Look for errors in the startup logs
- Verify the migration chain is correct (each migration references the previous one)
If you need to manually run migrations for debugging:
./env/bin/alembic upgrade headHowever, the application normally handles this automatically.