docs: empty Op.or & Op.not now throw in v7 - #841
Draft
WikiRik wants to merge 1 commit into
Draft
Conversation
Rewrites the "Changes to empty OR & NOT operators" section of the v7 upgrade guide to match sequelize/sequelize#18286, which makes an empty Op.or or Op.not throw instead of compiling to no condition at all. The section previously documented the alpha behaviour introduced by sequelize/sequelize#15598 as final. Also drops the stale `not({})` example: v7 exports `and()` and `or()`, but there is no `not()` helper. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documents sequelize/sequelize#18286. Draft — do not merge until that PR lands.
Why
The v7 upgrade guide has a section,
### Changes to empty OR & NOT operators, that documents the behaviour introduced by #15598: an emptyOp.ororOp.notis completely ignored, sowhere: or([])producesSELECT * FROM "users"with no condition.#18286 reverses that. Both now throw, because ignoring the operator silently widens the query to every row — including for
Model.updateandModel.destroy, where it defeats the safeguard that refuses to run those methods without awhere. Once #18286 lands, the current section documents behaviour that no longer exists.What changed
OR&NOToperators now throw", and attributed to both #15598 and #18286.0=1→ ignored → throws), naming the alpha window (7.0.0-alpha.24through7.0.0-alpha.48) in which the ignoring behaviour shipped, so readers upgrading between alphas can tell which one they are on.{ firstName: { [Op.or]: [] } }) and nested ({ [Op.and]: [{ ... }, { [Op.or]: [] }] }) cases that #18286 also covers.sql`1 = 0`to match no rows, or omitting the operator to apply no condition.Op.orfrom a list that turned out empty is the common way to hit this.:::infonote thatOp.andis deliberately not affected — an empty conjunction is vacuously true, so{ [Op.and]: [] }correctly stays "no condition". #18286 pins this with tests; the note is there so it does not get "fixed" for symmetry later.Drive-by fix
The old example used
not({}). There is nonot()export in v7 —packages/core/src/sequelize.jsexportsand()andor()only. Replaced withor({})and theOp.notobject forms, which are real.Checks
prettier --check docs/other-topics/upgrade.mdclean (run with 3.5.3 rather than the pinned 3.8.2; CI covers the pinned version).:::infoadmonition already used elsewhere in this file.Created by Opus 5 with Claude Code, supervised by @WikiRik.