simonw / sqlite-migrate Goto Github PK

I'm going to test this with a fresh install of llm to make sure it doesn't break.

Although... here's an interesting callenge with LLM: I frequently run many different copies of it against the same llm.db database stashed away in my ~/Library/Application Support folder.

It's perfectly possible I'll run an LLM upgraded instance which will upgrade the database... but then re-run an older version against the same DB in a way that will break things.

Originally posted by @simonw in #6 (comment)

Based on https://github.com/simonw/llm/blob/0.6/llm/migrations.py

Lint failure: https://github.com/simonw/sqlite-migrate/actions/runs/8270287510/job/22627467914

4 files would be left unchanged.
warning: `ruff <path>` is deprecated. Use `ruff check <path>` instead.
tests/test_sqlite_migrate.py:78:11: F841 Local variable `db` is assigned to but never used
Found 1 error.
No fixes available (1 hidden fix can be enabled with the `--unsafe-fixes` option).
Error: Process completed with exit code 1.

README currently just talks about the CLI.

See here:

• simonw/llm#162 (comment)

Should be able to do this:

sqlite-utils migrate data.db path/to/migrations.py

As an alternative to the current automatic discovery.

Should provide more examples, and cover things like the --list command.

In writing a test for a migration for this issue:

• simonw/llm#217

I realized I wanted to apply migrations up to a specific point, then run some test code, then apply the rest.

I think .apply() should take an optional second argument, stop_before="name".

Currently:

sqlite-utils migrate data.db --list
Pending migrations for data.db:

For LLM I got into a habit of doing this:

@migration()
def m001_create_table(db):
    # db is a sqlite-utils Database instance
    db["creatures"].create(
        {"id": int, "name": str, "species": str},
        pk="id"
    )

@migration()
def m002_add_weight(db):
    # db is a sqlite-utils Database instance
    db["creatures"].add_column("weight", float)

Because I was using the function names as the primary key in the database and I wanted them to naturally be displayed in the correct order in Datasette.

I can do better than that.

I had to add this to mypy.ini in LLM:

[mypy-sqlite_migrate.*]
ignore_missing_imports = True

Discovered when I had two separate migrations with different migration_set names but the same step name.

The first migration:

from sqlite_migrate import Migrations

m1 = Migrations("m1")

@m1()
def m001_init(db):
    pass

The second:

from sqlite_migrate import Migrations
m2 = Migrations("m2")

@m2()
def m001_init(db):
    pass

The m1.m001_init() step runs successfully, but m2.m001_init() is skipped. This is because they share the same step name m001_init, but they should have a different namespace anyway.

Caused by this, I think: