Multi-module projects

A project can keep migrations in more than one directory — one folder per module, service, or vendor tree. List every directory in migrations.directories. DBLift reads them as one set; which of the discovered files a given run applies is decided by the command's flags.

Layout

my-project/
├── dblift.yaml
├── core/
│   └── migrations/
│       ├── V1_0_0__core_tables.sql
│       └── V1_0_1__core_functions.sql
├── auth/
│   └── migrations/
│       └── V2_0_0__auth_tables.sql
└── billing/
    └── migrations/
        └── V3_0_0__billing_tables.sql

directories

migrations:
  directories:
    - ./core/migrations
    - ./auth/migrations
    - ./billing/migrations

Setting directories makes the older single directory key inert — it is not appended to the list. With neither set, DBLift reads ./migrations.

See migrations for the keys table.

Per-directory recursive

A directory entry is either a plain path or a path with its own recursive setting. Mixing both forms in one list is fine.

migrations:
  directories:
    - path: ./core/migrations
      recursive: true
    - path: ./auth/migrations
      recursive: false
    - ./billing/migrations
  recursive: true

recursive on the migrations section is the default for any entry that does not set its own. The built-in default is true.

Tags

Filename tags group scripts across those directories. A bracketed, comma-separated group anywhere in the name is read as tags — see Naming conventions for the syntax.

V1_0_0__create_users[core,init].sql
V1_0_1__create_auth[core,auth].sql
V2_0_0__add_billing[billing].sql

dblift migrate --tags=auth
dblift migrate --exclude-tags=billing

--tags, --exclude-tags, --versions and --exclude-versions scope migrate, undo, validate and diff to subsets of the script tree.