You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Preparation and schedule Drift queries rely on non-primary-key predicates without explicit table indexes, and preparation linked-list reconstruction is quadratic in the number of steps. This is small today, but it adds avoidable latency risk as local schedule/preparation data grows.
Related: #392. Any index/schema change should be coordinated with the Drift migration work there so existing installs get tested upgrade paths.
Evidence
lib/data/tables/preparation_schedule_table.dart and lib/data/tables/preparation_user_table.dart define only primary keys; scheduleId, userId, and nextPreparationId are queried but not explicitly indexed.
PreparationScheduleDao.getPreparationSchedulesByScheduleId filters by scheduleId, then reconstructs order with nested scans.
PreparationUserDao.getPreparationUsersByUserId repeats the same pattern for userId.
Delete paths update by nextPreparationId, another unindexed predicate.
ScheduleDao.getSchedulesByDate filters by scheduleTime and joins through placeId; Schedules also defines only the primary key.
PreparationEntity.ordered already shows a linear map/set-based reconstruction approach that the DAOs can mirror or reuse.
Proposed direction
Add Drift indexes for the DAO access patterns:
preparation_schedules(schedule_id)
preparation_schedules(next_preparation_id)
preparation_users(user_id)
preparation_users(next_preparation_id)
schedules(schedule_time)
consider schedules(place_id) if join/query plans show it helps
Refactor DAO linked-list reconstruction to build stepById and referencedIds once, then walk the chain in O(n), with cycle/broken-chain protection consistent with existing preparation-chain validation docs.
Acceptance criteria
Drift schema declares and generates the needed indexes.
Problem
Preparation and schedule Drift queries rely on non-primary-key predicates without explicit table indexes, and preparation linked-list reconstruction is quadratic in the number of steps. This is small today, but it adds avoidable latency risk as local schedule/preparation data grows.
Related: #392. Any index/schema change should be coordinated with the Drift migration work there so existing installs get tested upgrade paths.
Evidence
lib/data/tables/preparation_schedule_table.dartandlib/data/tables/preparation_user_table.dartdefine only primary keys;scheduleId,userId, andnextPreparationIdare queried but not explicitly indexed.PreparationScheduleDao.getPreparationSchedulesByScheduleIdfilters byscheduleId, then reconstructs order with nested scans.PreparationUserDao.getPreparationUsersByUserIdrepeats the same pattern foruserId.nextPreparationId, another unindexed predicate.ScheduleDao.getSchedulesByDatefilters byscheduleTimeand joins throughplaceId;Schedulesalso defines only the primary key.PreparationEntity.orderedalready shows a linear map/set-based reconstruction approach that the DAOs can mirror or reuse.Proposed direction
Add Drift indexes for the DAO access patterns:
preparation_schedules(schedule_id)preparation_schedules(next_preparation_id)preparation_users(user_id)preparation_users(next_preparation_id)schedules(schedule_time)schedules(place_id)if join/query plans show it helpsRefactor DAO linked-list reconstruction to build
stepByIdandreferencedIdsonce, then walk the chain in O(n), with cycle/broken-chain protection consistent with existing preparation-chain validation docs.Acceptance criteria
Related: #392
Source: Codex codebase audit on 2026-06-28.