Is there an existing issue for this?
What happened?
Issue Overview
Several data-fetching methods in SupabaseService perform multiple sequential database queries for related user data.
For example:
- getTickets
- getTasks
- getTicketDetails
- getTaskDetails
These methods:
- Fetch a list of tickets/tasks/comments.
- Then, for each item, make additional queries to fetch creator/assignee/user info.
This creates an N+1 query pattern.
Steps to Reproduce
- Create a team with multiple members.
- Add 20–50 tasks or tickets.
- Call getTickets() or getTasks().
- Observe in logs or network panel that dozens of extra queries are executed (one per item for user info).
Expected Behavior
Related user data (creator, assignee, comment user) should be fetched in a single query using joins or views, not separate queries per row.
The number of database calls should be:
- O(1) per screen load
not
- O(n) per item.
Actual Behavior
For each ticket/task/comment:
- _getUserInfo() is called.
- This results in additional round-trips to the database.
- Performance degrades rapidly as data grows.
This will not scale for real teams.
Why this issue matters
This is not just micro-optimisation.
It directly affects:
- load time
- mobile data usage
- battery
- server cost
On real data sizes, this becomes a serious bottleneck.
Record
Is there an existing issue for this?
What happened?
Issue Overview
Several data-fetching methods in SupabaseService perform multiple sequential database queries for related user data.
For example:
These methods:
This creates an N+1 query pattern.
Steps to Reproduce
Expected Behavior
Related user data (creator, assignee, comment user) should be fetched in a single query using joins or views, not separate queries per row.
The number of database calls should be:
not
Actual Behavior
For each ticket/task/comment:
This will not scale for real teams.
Why this issue matters
This is not just micro-optimisation.
It directly affects:
On real data sizes, this becomes a serious bottleneck.
Record