feat(cli): add database usage, backup list, restore, and connection rotate#106
Conversation
…otate Extends the database group with the remaining Management API surface: - database usage <database> [--from --to]: operations and storage metrics for a period - database backup list <database> [--limit]: platform-created backups with retention metadata - database restore <database> --backup <id> [--source-database <db>] --confirm <database-id>: destructive in-place restore; status goes to recovering and connections/credentials are preserved - database connection rotate <connection> --confirm <connection-id>: mints new credentials and prints the new one-time URL exactly once on stdout, matching the connection create output contract Restore and rotate follow the exact-id --confirm convention because they are destructive (restore overwrites data; rotate revokes the previous credentials). All commands support --json with structured error codes (DATABASE_BACKUPS_UNSUPPORTED, DATABASE_BACKUP_NOT_FOUND, DATABASE_RESTORE_CONFLICT) for agent consumption. Spec-first: command-spec.md and resource-model.md updated alongside the implementation.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
Summary by CodeRabbit
WalkthroughThis PR adds four new database CLI capabilities: Changes
Sequence Diagram(s)sequenceDiagram
participant CLI
participant Controller
participant DatabaseProvider
CLI->>Controller: runDatabaseUsage(context, ref, flags)
Controller->>Controller: parseUsageDate(from/to)
Controller->>DatabaseProvider: getUsage(databaseId, period)
DatabaseProvider-->>Controller: DatabaseUsageRecord
Controller-->>CLI: DatabaseUsageResult
CLI->>Controller: runDatabaseRestore(context, ref, flags)
Controller->>Controller: requireExactConfirmation
Controller->>DatabaseProvider: restoreDatabase(input)
DatabaseProvider-->>Controller: outcome
Controller-->>CLI: DatabaseRestoreResult
Related Issues: None referenced in the provided changes. Related PRs: None referenced in the provided changes. Suggested labels: feature, cli, database, documentation Suggested reviewers: Reviewers familiar with the CLI database command family, Management API provider integration, and confirmation/error-handling conventions. Poem 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/product/command-spec.md`:
- Around line 1041-1053: Add the missing confirmation-failure behavior to the
rotation docs in the command spec: update the `database connection rotate`
section that already references `--confirm <connection-id>` and `--yes` so it
explicitly states the structured `CONFIRMATION_REQUIRED` error is returned when
the confirmation value is missing or does not exactly match. Keep the wording
aligned with the existing output/error contract in this block so JSON consumers
can reliably detect and handle the failure path.
- Around line 930-938: Update the restore command spec section to include the
missing structured failure cases promised by the PR contract. In the restore
flow description near the existing `database restore` validation bullets, add
the `DATABASE_BACKUP_NOT_FOUND` failure for an invalid or missing `--backup
<backup-id>` and add `CONFIRMATION_REQUIRED` for a missing or mismatched
`--confirm <database-id>` value. Keep the wording aligned with the surrounding
restore validation rules and place these alongside the existing
`DATABASE_RESTORE_CONFLICT`, `DATABASE_NOT_FOUND`, and `DATABASE_AMBIGUOUS`
entries so the `database restore` documentation fully matches the command
behavior.
In `@packages/cli/src/controllers/database.ts`:
- Around line 492-500: The restore confirmation flow in database restore is
dropping the resolved source database from the recovery command. Update the
nextStep passed to requireExactConfirmation in database restore so it preserves
the source database identifier via --source-database alongside the backup and
confirm target, using the resolved database/backup values already available in
database.ts.
- Around line 366-368: The usage date check in database controller logic is too
permissive because Date.parse can accept non-ISO datetime strings and invalid
calendar dates. Tighten parseUsageDate so it only accepts strict YYYY-MM-DD
input and rejects invalid dates, then update the from/to comparison in the
database controller to compare the normalized date strings directly instead of
parsing them again.
In `@packages/cli/src/presenters/database.ts`:
- Around line 443-456: The backup list serializer is dropping each item’s real
status by hardcoding status to null in serializeDatabaseBackupList, which
weakens the standard list envelope for JSON consumers. Update the mapping in
serializeDatabaseBackupList so each backup item passes through backup.status
into the serializeList item status field, keeping the existing noun/label/id
structure intact and preserving the same serialization shape used by the list
presenters.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: b546c46a-7364-4fa4-8201-5f50bd9f3ac4
📒 Files selected for processing (11)
docs/product/command-spec.mddocs/product/resource-model.mdpackages/cli/fixtures/mock-api.jsonpackages/cli/src/adapters/mock-api.tspackages/cli/src/commands/database/index.tspackages/cli/src/controllers/database.tspackages/cli/src/lib/database/provider.tspackages/cli/src/presenters/database.tspackages/cli/src/shell/command-meta.tspackages/cli/src/types/database.tspackages/cli/tests/database.test.ts
- Validate --from/--to strictly: accept YYYY-MM-DD (expanded to midnight UTC, matching the API's ISO datetime contract) or a full ISO datetime, and reject rollover dates like 2026-02-30 that Date.parse silently accepts - Keep --source-database in the CONFIRMATION_REQUIRED recovery command for cross-database restores - Document DATABASE_BACKUP_NOT_FOUND and the date normalization rules in the command spec
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/cli/tests/database.test.ts`:
- Around line 594-611: The `rejects impossible calendar dates for usage periods`
test only covers a date-only rollover case, but `database.usage` also accepts
ISO datetimes. Extend this test in `packages/cli/tests/database.test.ts` by
adding a datetime rollover input alongside `--from "2026-02-30"` to cover the
datetime parsing branch as well. Keep the same assertions on
`executeCli`/`payload` so both supported formats are validated by the
`database.usage` command path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7e6ee1bd-05e6-468a-934d-cd5ebbc4997f
📒 Files selected for processing (3)
docs/product/command-spec.mdpackages/cli/src/controllers/database.tspackages/cli/tests/database.test.ts
… runner usage/backup/restore/rotate recovery commands, confirmation nextSteps, and result nextSteps now render through the project's package runner (pnpm dlx / bunx / npx -y with @prisma/cli@latest) instead of the hardcoded prisma-cli bin name, matching the agent group's convention. The management provider takes an optional formatter so its error factories stay consistent with the invoking directory.
luanvdw
left a comment
luanvdw
left a comment
There was a problem hiding this comment.
Nice work on this @AmanVarshney01
The overall shape looks right to me, one thing to consider fixing before merge, date-only --to currently normalizes the same way as --from, so --to 2026-06-30 becomes 2026-06-30T00:00:00.000Z before it is sent as endDate (packages/cli/src/controllers/database.ts). The spec/example reads like a calendar-day-inclusive range (--from 2026-06-01 --to 2026-06-30 for June usage), but this ends the query at the very start of June 30 unless the API has hidden special handling for that case.
What about either expand date-only --to to the end of the UTC day, or explicitly document --to as an instant bound and adjust the example. I’d also add a focused test so we don’t lock in the current midnight behavior.
I ran the focused database tests, tsc --noEmit, and git diff --check and all tests passed passed, so this flag is more a narrow contract fix rather than a broad implementation concern.
A date-only --to normalized to midnight, so --from 2026-06-01 --to 2026-06-30 ended the query at the very start of June 30 unless the API applied its own end-of-day handling. Calendar dates now expand per-bound (--from to start of day, --to to end of day) so the range is calendar-day inclusive by contract, not by server behavior. Adds the new database error codes to error-conventions.md and a same-day range test.
AmanVarshney01
dismissed stale reviews from luanvdw and coderabbitai[bot]
via
3576c87
|
@luanvdw Good catch, fixed in 3576c87: a calendar-date |
Completes the `project` group's remote lifecycle: rename, remove, and transfer. Spec-first (`command-spec.md` + `resource-model.md` updated in the same change). ```bash $ prisma-cli project rename "Acme Dashboard v2" ✔ Renamed. Directory bindings pin the project id, so they stay valid. $ prisma-cli project remove proj_999 --confirm proj_999 ✔ The project, its databases, and its apps were removed. This directory's local project binding was cleared. $ prisma-cli project transfer proj_123 --to-workspace "Prisma Labs" --confirm proj_123 ✔ The project now belongs to the recipient workspace. This directory's local project binding now points at the recipient workspace. ``` Design notes - The transfer API authorizes with a recipient *access token*, not a workspace id. `--to-workspace` resolves a locally stored OAuth session (same targets as `auth workspace use`) through a new workspace-pinned `FileTokenStorage` view that refreshes via the SDK and can never move the active-workspace selection; `--recipient-token` is the cross-account/headless path. Under `PRISMA_SERVICE_TOKEN`, `--to-workspace` fails with `TRANSFER_RECIPIENT_UNAVAILABLE`. - Remove and transfer take an explicit positional target (never the bound project) plus exact-id `--confirm`. - Local pin hygiene: remove clears a matching `.prisma/local.json`; transfer rewrites it to the recipient workspace when known, else clears it; both best-effort with warnings. - Structured codes: `PROJECT_REMOVE_BLOCKED` (active deployments), `PROJECT_TRANSFER_REJECTED`, `PROJECT_RENAME_FAILED`, `TRANSFER_RECIPIENT_REQUIRED`/`_UNAVAILABLE`, `CONFIRMATION_REQUIRED` with meta. Testing: 14 new integration tests, full suite green, and all three commands verified against the live Management API with scratch projects, including a real cross-workspace transfer (project visible in the recipient workspace, pin rewritten, cleaned up afterwards). Note: merge after #106 or rebase; both touch `mock-api.ts`/fixtures.
2 participants
Adds the remaining Prisma Postgres surface to the
databasegroup: usage metrics, backups, restore, and credential rotation. Spec-first (command-spec.md+resource-model.mdupdated in the same change).Design notes
--confirmconvention;--yesnever satisfies it.--source-database(e.g. a production backup into a scratch database).DATABASE_BACKUPS_UNSUPPORTED(remote/BYO),DATABASE_BACKUP_NOT_FOUND,DATABASE_RESTORE_CONFLICT(target provisioning/recovering), plusCONFIRMATION_REQUIREDwithexpectedConfirm/receivedConfirmmeta.--from/--toacceptYYYY-MM-DD(expanded to midnight UTC, matching the API's ISO-datetime contract) or a full ISO datetime; impossible dates like2026-02-30are rejected.Testing: 13 new integration tests (27 in the file), full suite green, and every command verified against the live Management API on a scratch database (rotation genuinely minted new credentials; restore's 404/conflict paths exercised).