Duplicate Check Repository
Component Detail
Description
Data access layer that wraps the Supabase RPC for duplicate detection. Constructs the parameterised RPC call with peer_mentor_id, activity_type_id, and date, and maps the raw Supabase response to typed Dart model objects for use by service layer consumers.
duplicate-check-repository
Summaries
The Duplicate Check Repository is the technical foundation that makes real-time duplicate detection possible during activity submission. By encapsulating the database logic that identifies whether a peer mentor has already logged the same type of activity on the same date, this component enables the system to surface conflicts before they become data quality problems. This prevents inflated activity tallies, protects the integrity of mentor performance records, and reduces the manual correction burden on coordinators. Reliable, accurate duplicate detection at submission time is a core data quality safeguard that supports trustworthy reporting to program funders and reduces the operational cost of post-submission data audits.
The Duplicate Check Repository is a medium-complexity data layer component with no declared dependencies on other custom components — it interfaces directly with Supabase via RPC. This makes it a relatively self-contained deliverable, but it requires close coordination with the database team to ensure the Supabase RPC function is defined, parameterised correctly, and returns the expected schema. Testing must cover successful RPC responses, empty result sets (no duplicate found), and failure modes including network errors and malformed responses. Since the Duplicate Resolution Handler and Duplicate Detection Service both depend on this repository, delays here will cascade to those downstream components.
Typed exception handling for RPC errors should be agreed upon early to avoid integration friction.
The Duplicate Check Repository wraps the Supabase RPC call for duplicate detection and provides four interfaces: callDuplicateCheckRpc() with peer_mentor_id, activity_type_id, and date parameters; insertWithReviewedFlag() for the proceed resolution path; updateExistingRecord() for the merge path; and getActivityById() for record retrieval. The RPC response is deserialised into typed ActivityCandidate model objects — this mapping must be kept in sync with any schema changes to the underlying Supabase function. Error handling should produce typed exceptions (e.g., DuplicateCheckNetworkException, DuplicateCheckParseException) so callers can distinguish retriable errors from logic failures. All Supabase client calls should be async and non-blocking.
This is the only component that issues direct database reads for duplicate detection, making it the authoritative source for that data contract.
Responsibilities
- Execute Supabase RPC for duplicate detection with correct parameter mapping
- Deserialise RPC response rows into ActivityCandidate model objects
- Handle RPC errors and network failures with typed exceptions
- Insert new activity record with duplicate_reviewed flag when required
Interfaces
callDuplicateCheckRpc(peerId, activityTypeId, date)
insertWithReviewedFlag(activityData)
updateExistingRecord(activityId, updates)
getActivityById(activityId)
Relationships
Dependents (2)
Components that depend on this component
Used Integrations (1)
External integrations and APIs this component relies on