mirror of
https://github.com/CherryHQ/cherry-studio.git
synced 2026-07-03 12:27:41 +08:00
6ec914cf0f
### What this PR does Before this PR: - `file_entry` table used `trashed_at` for the soft-delete timestamp, diverging from every other soft-deletable table in the schema (`agent`, `assistant`, `message`, `topic`), which all use `deleted_at`. After this PR: - `file_entry.deleted_at` (and BO field `deletedAt`) — naming is consistent across the entire schema. - Renamed identifiers: - Schema field: `trashedAt` → `deletedAt` - SQL column: `trashed_at` → `deleted_at` - Index: `fe_trashed_at_idx` → `fe_deleted_at_idx` - CHECK constraint: `fe_external_no_trash` → `fe_external_no_delete` - Updated all source files, tests, and architecture docs (including `v2-refactor-temp/docs/file-manager/`). - **Intentionally NOT renamed** (out of scope — these are API surface / concept names, not the column name): `moveToTrash`, `restoreFromTrash`, `inTrash` (query flag), `isTrashed`, `batchTrash`, `internalTrash`, and "Trash" as a concept in comments/docs. Fixes # ### Why we need it and why it was done in this way The following tradeoffs were made: - **Scope discipline**: kept the rename strictly at the column-identifier layer (4 identifiers). Did not change API names or concept words — switching the "Trash" concept to "Delete" is a larger semantic change that deserves its own PR. - **Migration 0026 contains a manual SQL patch.** drizzle-orm/drizzle-kit issue [#3653](https://github.com/drizzle-team/drizzle-orm/issues/3653) causes the SQLite rebuild-table path to drop the leading `ALTER TABLE … RENAME COLUMN` statement. The generated `INSERT … SELECT "deleted_at" FROM file_entry` would fail because the source table still has `trashed_at`. The migration manually prepends an explicit `ALTER TABLE file_entry RENAME COLUMN trashed_at TO deleted_at;` before the rebuild. Upstream fix landed in `drizzle-kit@1.0.0-beta`/`rc` but is not backported to the `0.31.x` stable line we depend on. - **Why keeping the manual patch is acceptable**: per `CLAUDE.md` § v2 Refactoring, `migrations/sqlite-drizzle/` is throwaway during v2 — it will be wiped and regenerated as a single clean initial migration from the final schemas before release. Mid-development DB drift is explicitly acceptable, and the manual SQL only needs to survive until that regeneration. The following alternatives were considered: - Selecting `create column` in `drizzle-kit generate` instead of `rename column`: also produces invalid SQL (same root cause — the rebuild path puts the new column name in the `SELECT` list regardless of the rename mapping). Rejected. - Skipping the `0026` migration entirely and relying on `db:push` / DB reset during dev: pollutes `_journal.json` divergence and makes the next schema change confusing. Rejected. - Upgrading to `drizzle-kit@1.0.0-beta`/`rc` to get the fix: v1 is a major rewrite with significant breaking changes (alternation engine rewrite, ORM type system rewrite, migration folder layout change). Out of scope for this PR. Rejected. Links to places where the discussion took place: N/A ### Breaking changes None. Dev-only DB column rename during v2 refactor. No user-visible behavior change. No public API surface change. v1 data never reaches this branch except through migrators in `src/main/data/migration/v2/`. ### Special notes for your reviewer - The single manual edit to drizzle-generated SQL is in `migrations/sqlite-drizzle/0026_sturdy_aqueduct.sql` — look for the `MANUAL PATCH` comment block at the top. Without it the migration will fail to apply. - "Trash" concept words still appear throughout the file-manager codebase by design (function names, comments, docs section headings). If we later want to migrate the whole concept to "Delete", that should be a follow-up PR. ### Checklist This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR. Approvers are expected to review this list. - [x] PR: The PR description is expressive enough and will help future contributors - [x] Code: [Write code that humans can understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans) and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle) - [x] Refactor: You have [left the code cleaner than you found it (Boy Scout Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) - [x] Upgrade: Impact of this change on upgrade flows was considered and addressed if required - [ ] Documentation: A [user-guide update](https://docs.cherry-ai.com) was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior. - [x] Self-review: I have reviewed my own code (e.g., via [`/gh-pr-review`](/.claude/skills/gh-pr-review/SKILL.md), `gh pr diff`, or GitHub UI) before requesting review from others ### Release note ```release-note NONE ``` --------- Signed-off-by: icarus <eurfelux@gmail.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
THIS DIRECTORY IS NOT FOR RUNTIME USE
v2 Data Refactoring Notice
Before the official release of the alpha version, the database structure may change at any time. To maintain simplicity, the database migration files will be periodically reinitialized, which may cause the application to fail. If this occurs, please delete the cherrystudio.sqlite file located in the user data directory.
- Using
libsqlas thesqlite3driver, anddrizzleas the ORM and database migration tool - Table schemas are defined in
src\main\data\db\schemas migrations/sqlite-drizzlecontains auto-generated migration data. Please DO NOT modify it.- If table structure changes, we should run migrations.
- To generate migrations, use the command
yarn run db:migrations:generate