[C4GT Community]: Implement a repository pattern using sqlite storage for GeolocationQueryService #26
Description
Ticket Contents
Description
Issue #12 covers a high complexity objective to implement /geo api endpoint. In order to list facilities, implement a repository to be consumed from GeolocationQueryService.
Background:
The project has 3 primary levels:
- IO layer: all infrastructural/mutating transactions. --> We want to implement repository storage here.
- application services: services that consume the domain layer and are consumed by the IO layer.
- domain: the ƒat business logic. --> We want to define interface signatures here.
The project src directory contains the following:
xcov19
├── app: Contains web framework, application services, routes, dto related modules.
│ ├── auth.py
│ ├── binders.py
│ ├── controllers
│ │ ├── diagnose.py
│ │ └── geolocation.py
│ ├── docs
│ │ └── binders.py
│ ├── dto.py
│ ├── errors.py
│ ├── main.py
│ ├── middleware.py
│ ├── services.py
│ └── settings.py: configuration and settings to run server with.
├── dev.py: runs server in developer mode
├── domain: contains the entities, values and aggregates for business domain context
│ ├── common.py
│ ├── models
│ │ ├── patient.py
│ │ └── provider.py
│ └── repository.py: Repository that abstracts away storage implementation and manages application logic between domain aggregate and data store for a specific context.
└── utils
└── mixins.py
The GeolocationQueryService is an application service consumed by the web api route geo. See here.
The service needs to query the storage layer via a storage repository. This repository is called by the patient query look up service which is a callable and it calls the repository passing relevant parameters available in the set of: [Address, LocationQueryJSON, List[FacilitiesResult]] which are defined in dto.py.
In the repository pattern, extend IProviderStore interface in domain/models/provider.py and implement a provider store with implementation in sqlite to allow GeolocationQueryService to fetch healthcare providers in a storage -agnostic manner.
See You Wanted Banana and API First design for motivation
Goals
Goals
- Understand a reproducible 'hello world' example of repository pattern
- Identify parameters to consume in order to implement the repository
- Identify the expected return value and edge cases for return type from repository
- Identify type signature and annotations for interface and sqlite implementation
- Implement the Provider Repository in order to be able to return list of facilties.
- Have unit test coverage
- All major use cases have been identified
Expected Outcome
- Unit test should be able to demonstrate a fake repository implementation using a stub storage that lives only for test session. Refer to the attached wireframe for the flow.
- The repository implementation should take in the provided parameters and return either a list of care facility records or nothing.
Acceptance Criteria
- The implementation repository is in
repository.pyunder apps/ module - The interface conforms to requirements and can be tested against in the test run.
- All tests including Automation tests run successfully for repository
Implementation Details
The repository’s role is to handle the persistence of aggregates.
Refer to dto.py and provider.py in order to understand the flow as described here.
The Repository receives aggregate as input parameters so first think and map the necessary DTOs to aggregate. The caller service transforms DTO to aggregates.
The repository takes in and preprocesses query_id, cust_id in addition to geo location coordinates in order to call sqlite db and return a list of records, the return schema for which is defined in #12 ; The repository takes in the aggregate Provider in provider.py and performs a geo-query to filter all records that are within 50 kms of the patient's coordinates.
Query against the following tentative table attributes from the repository:
| columns name | type |
|---|---|
| query_id | alphanumeric string |
| cust_id | alphanumeric string |
| lat | float |
| lng | float |
| specialty | array[text] |
Expected return value
For each query_id and cust_id, filter down the coordinates lat and lng and return the data. Ignore the missing attributes from the attribute column that you cannot find. Let the missing return parameters be optional while maintaining strong consistency with the JSON Type format per attribute.
Mockups/Wireframes
Product Name
project-healthcare
Organisation Name
XCoV19
Domain
Healthcare
Tech Skills Needed
Database, Debugging, Flask, Python, SQL, Test, Testing Library
Mentor(s)
Complexity
High
Category
Backend, Database, Refactoring, Testing