🐛 Fixed incorrect date filtering on SQLite#28952
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (4)
WalkthroughA new Bookshelf 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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 `@ghost/core/core/server/models/base/plugins/date-filter.js`:
- Around line 60-72: The normalizeFieldValue logic in date-filter.js is treating
any object as an operator map, which incorrectly converts Date instances into
empty objects. Update normalizeFieldValue to only enter the
operator-normalization branch for plain objects containing $-prefixed operators,
and leave Date values unchanged; keep the array handling and normalizeValue
usage intact.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bc801781-9315-4c24-9fb0-c35e4eac0a55
📒 Files selected for processing (4)
ghost/core/core/server/models/base/bookshelf.jsghost/core/core/server/models/base/plugins/date-filter.jsghost/core/test/integration/model/post-date-filter.test.jsghost/core/test/unit/server/models/base/date-filter.test.js
fixes TryGhost#23441 - date columns are stored as "YYYY-MM-DD HH:MM:SS", but absolute date values in filters were passed through untouched while only relative dates (now-30d) were normalized - on SQLite, datetimes are stored as text and compared lexically, so the "T" in an ISO value sorts after the stored space separator and greater/less-than filters returned the wrong rows - normalizes date-column filter values to the stored UTC format before the query is built, leaving non-date columns and unparseable values untouched
3babb68 to
6c9f433
Compare
Got some code for us? Awesome 🎊!
Please take a minute to explain the change you're making:
Why are you making it?
Filtering by an absolute date returns the wrong rows on SQLite. Using
filter="published_at:>'...'"in a theme's{{#get}}, or the same filter via the Content/Admin API, includes posts from the wrong side of the boundary. Fixes Cannot get posts from the same date (SQLite3-specific?) #23441.What does it do?
Date columns are stored as
YYYY-MM-DD HH:MM:SS(UTC). NQL already normalizes relative dates (now-30d) to that format, but absolute values from a filter (for examplepublished_at:>'2025-02-27T19:03:00.000-05:00') are passed through untouched. On SQLite, datetimes are stored as text and compared lexically, so theTsorts after the space separator (T>) and the comparison is wrong. Relative dates work, absolute ISO dates don't.This adds a model filter plugin that normalizes absolute date values to the stored format before the query runs. It wraps
applyDefaultAndCustomFilterswith a schema-aware transformer that, fordateTimecolumns only, reparses the value (handling ISO 8601 with timezone offsets) and reformats it as UTCYYYY-MM-DD HH:mm:ss. Non-date columns and values it can't parse as a date are left untouched, so a post titled2025-02-27is never rewritten. Offsets are converted to UTC, which also corrects the same comparison on MySQL.Why is this something Ghost users or developers need?
Date-based filtering is a documented, widely used feature (date pagination, "newer/older than" lists, API queries). Today it quietly returns incorrect results on SQLite, the default database for self-hosted installs.
Please check your PR against these items:
We appreciate your contribution! 🙏