⚡ Bolt: [performance improvement] Optimize grievance query to use load_only#694
⚡ Bolt: [performance improvement] Optimize grievance query to use load_only#694RohanExploit wants to merge 2 commits intomainfrom
Conversation
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
✅ Deploy Preview for fixmybharat canceled.
|
🙏 Thank you for your contribution, @RohanExploit!PR Details:
Quality Checklist:
Review Process:
Note: The maintainers will monitor code quality and ensure the overall project flow isn't broken. |
📝 WalkthroughWalkthroughSQLAlchemy ORM queries in the daily grievance-loading cycle now use Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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.
Pull request overview
Optimizes the daily civic intelligence job’s grievance fetch by loading only the ORM fields that are actually used, reducing DB I/O and memory overhead.
Changes:
- Update the grievance query to use
options(load_only(Grievance.id, Grievance.category)). - Adjust the unit test’s mocked SQLAlchemy query chain to include
.options(...). - Add a Bolt learning entry documenting how to mock
load_only-augmented queries.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| backend/civic_intelligence.py | Uses load_only when loading grievances for the daily cycle to avoid fetching unused columns. |
| backend/tests/test_civic_intelligence.py | Updates mock query chaining to match the new .options(...).filter(...).all() call pattern. |
| .jules/bolt.md | Documents the testing/mocking change required when adding .options(load_only(...)). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.jules/bolt.md:
- Around line 81-83: The entry heading "## 2026-05-18 - Mocking SQLAlchemy
load_only options" is dated in the future; update the heading date to the PR
creation/learning date (e.g., change "2026-05-18" to "2026-04-21") so the
timeline is accurate, leaving the rest of the heading and content unchanged.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9a7f2c7c-2080-40bc-8fe3-1a258c911d39
📒 Files selected for processing (3)
.jules/bolt.mdbackend/civic_intelligence.pybackend/tests/test_civic_intelligence.py
| ## 2026-05-18 - Mocking SQLAlchemy load_only options | ||
| **Learning:** When changing a database query from `db.query(Model)` to `db.query(Model).options(load_only(...))` to optimize data fetching, the return type remains the ORM model (unlike column projection which returns tuples). However, if the tests mock the SQLAlchemy query chain, the mock assertions will fail because `.options()` is added to the chain. | ||
| **Action:** When adding `.options(load_only(...))` to a query, always ensure the corresponding mock queries in tests are updated to include `.options.return_value` (e.g., `mock_query.options.return_value.filter.return_value.all.return_value = ...`) to correctly mock the new chain. |
There was a problem hiding this comment.
Fix the future-dated learning entry.
This PR was created on April 21, 2026, but the new entry is dated May 18, 2026. Please update the heading date to the actual learning date to keep the timeline accurate.
📝 Proposed documentation fix
-## 2026-05-18 - Mocking SQLAlchemy load_only options
+## 2026-04-21 - Mocking SQLAlchemy load_only options📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## 2026-05-18 - Mocking SQLAlchemy load_only options | |
| **Learning:** When changing a database query from `db.query(Model)` to `db.query(Model).options(load_only(...))` to optimize data fetching, the return type remains the ORM model (unlike column projection which returns tuples). However, if the tests mock the SQLAlchemy query chain, the mock assertions will fail because `.options()` is added to the chain. | |
| **Action:** When adding `.options(load_only(...))` to a query, always ensure the corresponding mock queries in tests are updated to include `.options.return_value` (e.g., `mock_query.options.return_value.filter.return_value.all.return_value = ...`) to correctly mock the new chain. | |
| ## 2026-04-21 - Mocking SQLAlchemy load_only options | |
| **Learning:** When changing a database query from `db.query(Model)` to `db.query(Model).options(load_only(...))` to optimize data fetching, the return type remains the ORM model (unlike column projection which returns tuples). However, if the tests mock the SQLAlchemy query chain, the mock assertions will fail because `.options()` is added to the chain. | |
| **Action:** When adding `.options(load_only(...))` to a query, always ensure the corresponding mock queries in tests are updated to include `.options.return_value` (e.g., `mock_query.options.return_value.filter.return_value.all.return_value = ...`) to correctly mock the new chain. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.jules/bolt.md around lines 81 - 83, The entry heading "## 2026-05-18 -
Mocking SQLAlchemy load_only options" is dated in the future; update the heading
date to the PR creation/learning date (e.g., change "2026-05-18" to
"2026-04-21") so the timeline is accurate, leaving the rest of the heading and
content unchanged.
💡 What: Replaced full ORM loading of the Grievance model with
.options(load_only(Grievance.id, Grievance.category))in the daily civic intelligence job.🎯 Why: Selecting full SQLAlchemy model instances is slower and uses more memory, especially as the number of upgrades scales up, and only the id and category fields were needed.
📊 Impact: Reduces memory usage and database I/O for fetching associated grievances by avoiding loading unnecessary fields like
action_plananddescriptionwhile maintaining the ORM object structure.🔬 Measurement: Verified that all 107 tests pass in the backend suite and the logic correctly interacts with the object properties.
PR created automatically by Jules for task 4290250909438725555 started by @RohanExploit
Summary by CodeRabbit
Release Notes
Refactor
Tests
Summary by cubic
Optimized the grievance lookup in the daily civic intelligence job by using SQLAlchemy
load_onlyto fetch onlyidandcategory. This reduces DB I/O and memory; tests now mock the.options(...).filter().all()chain to cover the new query path.Written for commit fbe885f. Summary will update on new commits.