Summary
Managing an app installation's linked database (link / unlink / repurpose / replace) is only possible via the raw HTTP API today — there is no mw subcommand for it. In otherwise CLI-driven workflows (e.g. migrations) this forces hand-rolled curl calls against the OpenAPI spec.
Verified against mw 1.19.0.
What's missing
mw app exposes no database-related subcommand:
app copy / download / exec / get / list / list-upgrade-candidates /
open / ssh / uninstall / update / upgrade / upload / version-info / versions
…but the API has a full set of app↔database operations:
| Operation |
API endpoint (operationId) |
| Link a DB to an app |
PATCH /v2/app-installations/{id}/database (app-link-database) |
| Unlink a DB |
DELETE /v2/app-installations/{id}/databases/{databaseId} (app-unlink-database) |
| Replace the linked DB |
PATCH /v2/app-installations/{id}/database/replace (app-replace-database) |
| Set DB users |
PUT /v2/app-installations/{id}/databases/{databaseId}/users (app-set-database-users) |
Why it hurts
The link body is non-obvious and easy to get wrong when hand-rolling:
PATCH /v2/app-installations/{id}/database
{ "databaseId": "<uuid>", "purpose": "primary|cache|custom", "databaseUserIds": { "admin": "<databaseUserId>" } }Two sharp edges hit while doing it by hand:
-
databaseUserIds is required in practice (the call fails without databaseUserIds.admin) even though the schema lists only databaseId + purpose as required.
-
The validation error message misspells the field as databaseUserIDs (capital IDs) while the accepted field is databaseUserIds:
"message": "database user 'admin' required",
"path": "databaseUserIDs",
"context": { "missingProperty": "databaseUserIDs.admin" }
Request
- Add
mw app database link | unlink | replace (or equivalent under mw database) mirroring the API above.
- Independently: fix the validation error casing (
databaseUserIDs → databaseUserIds) so the message matches the accepted payload.
Context
Surfaced while building and validating the mittwald-migrate skill. Filing upstream (API-supported but CLI-missing) rather than baking a curl workaround into the skill.
Summary
Managing an app installation's linked database (link / unlink / repurpose / replace) is only possible via the raw HTTP API today — there is no
mwsubcommand for it. In otherwise CLI-driven workflows (e.g. migrations) this forces hand-rolledcurlcalls against the OpenAPI spec.Verified against
mw 1.19.0.What's missing
mw appexposes no database-related subcommand:…but the API has a full set of app↔database operations:
PATCH /v2/app-installations/{id}/database(app-link-database)DELETE /v2/app-installations/{id}/databases/{databaseId}(app-unlink-database)PATCH /v2/app-installations/{id}/database/replace(app-replace-database)PUT /v2/app-installations/{id}/databases/{databaseId}/users(app-set-database-users)Why it hurts
The link body is non-obvious and easy to get wrong when hand-rolling:
Two sharp edges hit while doing it by hand:
databaseUserIdsis required in practice (the call fails withoutdatabaseUserIds.admin) even though the schema lists onlydatabaseId+purposeasrequired.The validation error message misspells the field as
databaseUserIDs(capitalIDs) while the accepted field isdatabaseUserIds:Request
mw app database link | unlink | replace(or equivalent undermw database) mirroring the API above.databaseUserIDs→databaseUserIds) so the message matches the accepted payload.Context
Surfaced while building and validating the
mittwald-migrateskill. Filing upstream (API-supported but CLI-missing) rather than baking acurlworkaround into the skill.