[WEB-4657] refactor: optimize project v2 endpoint and issue detail endpoint #7558
Conversation
WalkthroughThe changes refactor queryset annotations in the issue-related views to use more explicit Subquery constructs for counting and aggregating related objects. Array aggregations for label, assignee, and module IDs now use subqueries on join tables. Eager loading is reduced by limiting select_related fields, and redundant filters and distinct calls are removed. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant IssueViewSet
participant DB
Client->>IssueViewSet: retrieve/list/get_queryset
IssueViewSet->>DB: Query Issue objects
Note right of IssueViewSet: Annotate using Subqueries for counts and aggregations
DB-->>IssueViewSet: Issue objects with annotated fields
IssueViewSet-->>Client: Response with annotated issue data
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~18 minutes Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
apps/api/plane/app/views/issue/base.py (1)
99-118: Inconsistent refactoring pattern across similar queries.While the
retrievemethod andIssuePaginatedViewSetmethods have been refactored to use the newSubquerypattern for count annotations, several other methods in the file still use the old pattern withFunc(F("id"), function="Count"):
IssueListEndpoint.get()(lines 99-118)IssueViewSet.get_queryset()(lines 216-235)IssueDetailEndpoint.get()(lines 1019-1038)IssueDetailIdentifierEndpoint.get()(lines 1224-1243)Consider applying the same refactoring pattern consistently across all similar queries for maintainability and performance consistency.
Also applies to: 216-235, 1019-1038, 1224-1243
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/api/plane/app/views/issue/base.py(5 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: in the plane codebase serializers, workspace_id is not consistently passed in serializer context, so...
Learnt from: NarayanBavisetti
PR: makeplane/plane#7460
File: apps/api/plane/app/serializers/draft.py:112-122
Timestamp: 2025-07-23T18:18:06.875Z
Learning: In the Plane codebase serializers, workspace_id is not consistently passed in serializer context, so parent issue validation in DraftIssueCreateSerializer only checks project_id rather than both workspace_id and project_id. The existing project member authentication system already validates that users can only access projects they belong to, providing sufficient security without risking breaking functionality by adding workspace_id validation where the context might not be available.
Applied to files:
apps/api/plane/app/views/issue/base.py
🔇 Additional comments (4)
apps/api/plane/app/views/issue/base.py (4)
17-19: Import additions look good.The addition of
SubqueryandCountimports is appropriate for the refactored query annotations.
457-531: Query optimization improvements are well-implemented.The refactoring to use
Subqueryconstructs for both count and array aggregations is a good optimization:
- More explicit and readable query construction
- Potentially better performance by operating directly on join tables
- Maintains all existing filter conditions (active members, non-archived modules)
The reduction in
select_relatedfields is appropriate if those fields aren't needed in the response serialization.
909-942: Array aggregation refactoring is consistent and correct.The refactoring to use
Subqueryfor array aggregations on join tables (IssueLabel,IssueAssignee,ModuleIssue) is consistent with the pattern used throughout the file and maintains all the necessary filter conditions.
795-830: Distinct removal is safe—no multi-valued joins to introduce duplicatesThe
get_querysetnow only applies:
- A simple filter on
Issue.issue_objectsselect_related("state"), which joins on a one-to-one/foreign-key- Subquery annotations (no JOINs to multi-valued relations)
Since there are no many-to-many or multi-row joins, dropping
.distinct()will not produce duplicate rows in pagination. No further changes needed.
dheeru0198
changed the title
|
Pull Request Linked with Plane Work Items
Comment Automatically Generated by Plane |
Description
This PR will optimize project v2 and issue details endpoints to use subquery for counts and arrays
Type of Change
Summary by CodeRabbit