Two cron / migration providers eagerly require modules they only need
at runtime:
- `services/cron.ts` imports `node-schedule` (~90 ms via `Job` class)
even when `server.cron` is empty. Defer the require to first
`add()` / `start()`.
- `database/src/migrations/{internal,users}.ts` instantiate `Umzug`
immediately in their factory, pulling in the inquirer and
`@rushstack/ts-command-line` chain. Move the construction inside a
lazy `provider()` closure so the require only fires on `shouldRun`,
`up`, or `down`.
~100 ms saved on every boot of a project without active cron tasks
or pending migrations (the common case).
* Use query builder init in deleteMany
* test(api): deleteMany respects filters combined with relation
* fix(database): pick filter params in deleteMany init
Apply _q, where, and filters through init like count instead of where-only
or full findMany params, avoiding populate/pagination surprises. Expand API
and unit tests for relation filters, count parity, and ignored param keys.
* chore(database): clarify deleteMany relation cleanup TODO
Replace the vague bulk-query TODO with a concrete note that deleteMany
still skips per-row deleteRelations unlike single delete().
---------
Co-authored-by: Ben Irvin <ben.irvin@strapi.io>
Co-authored-by: Ben Irvin <ben@innerdvations.com>
* Run batches of document_id creation
* fix(core): use better caching in discard-draft
* fix(core): improve batch sizing & document_id loop efficiency // more caching improvements
* fix(core): componentHierarchyCaches moved back outside the loop
* test(migrations): add new tests and update existing
---------
Co-authored-by: Ben Irvin <ben.irvin@strapi.io>
Co-authored-by: Ben Irvin <ben@innerdvations.com>
* feat: sort based on publish status
* chore: remove redundant `any` type assertions
* fix: override sort if `status` filter is present
* fix(content-manager): status sort ignored hasPublishedVersion and publicationStatusFilter
* fix(utils): remove unused STATUS_ATTRIBUTE constant
* fix(content-manager): missing deps in useEffect for status sort cleanup
---------
Co-authored-by: Ziyi <daydreamnation@live.com>
Previously the migration could leave the DB in an unbootable state after
a statement_timeout or process kill: the document_id column existed but
the migration was not recorded, and the retry crashed with PG 42701
"column already exists". Additionally, when hasColumn returned true
the migration early-exited via continue, silently skipping the backfill
and leaving rows with NULL document_id.
- Swallow duplicate-column errors (PG 42701, MySQL 1060, generic
/duplicate column/i) around ALTER TABLE ADD COLUMN to tolerate
catalog drift / operator-applied partial fixes.
- Always run the document_id backfill when the column exists; the
backfill already uses WHERE document_id IS NULL so it is a no-op on
fully-populated tables and recovery on partially-populated ones.
- Add unit tests covering fresh run, column-already-exists,
PG 42701, MySQL 1060, and non-duplicate errors.
Fixes CMS-689
* fix(core): handle time to dateTime and dateTime to time conversion with default value
* fix(core): add conversion utility function, fix linting
* fix: add eorror handling for getCurrentColumnType
* use transaction connection
* fix: escape set default placeholder
* fix(database): linting issue
In the migration 5.0.0-02-created-document-id, the GROUP BY in the SQL request does not precise the column's table which create an ambiguity when a content type use internationalization and one of its field is named "[name_of_the_type]Id".
Co-authored-by: Jamie Howard <48524071+jhoward1994@users.noreply.github.com>
Aurélien GEORGET
Weijie Sun
bartsmartshore
Ben Irvin
Florent Baldino
Jamie Howard
Dominik Juriga
Boaz Poolman
Ziyi
Yohei Yamamoto
guoyangzhen
markkaylor
Araksya Gevorgyan
dollaransh17
Bassel Kanso
Ziyi
DMehaffy
Jean-Sébastien Herbaux
Dhruv Maradiya
Ben Irvin
Nikolay Shebanov
Marvin Mottet
Marc Roig