-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement reusable data service #2714
Comments
Moritz and the curation team are reviewing this schema. Based on discussion including @abhidg and leads/curators yesterday, I think we want to treat the covid-19 collection and schema as its own thing and start from scratch with the day-zero schema (maybe just renaming the database from covid19 to $newdisease) in new instances, then configure them to support additional fields as the pandemic develops. |
Here's the plan @abhidg and I discussed yesterday. So the curator API has a configurable connection to a data service (which it already does), and rather than having a strict OpenAPI validator for cases accepts any object as a case and lets the data service validate its input and report errors: the curator API is responsible for user management, data source/ingestion management and access control. Existing UI has a lot of connection to new schema, but we can re-use automated source configuration, user profiles/management, overall structure so add new case list/forms for the new flexible schema and choose which to use per deployment. Geocoding API remains unchanged. The data API is completely replaced: the existing one has multiple constraints coupling it to the COVID-19 schema, so we'll have a new service for new diseases which encodes the day 0 schema plus custom fields. The covid-19 instances of G.h use the existing data service, and hMPXV/emerging outbreak instances use the new one instead. |
…rialise such dates #2714 I chose not to handle this in the mongo_store because it would have been (cognitively and computationally) inefficient: it would mean dumping the BSON, loading the JSON, patching it, dumping that, then loading in the model. Nein, danke!
The free text is stored in an associated string field
The free text is stored in an associated string field
Work on the curator UI captured in this issue: #2902 |
See Moritz's day zero schema on globaldothealth/monkeypox#21 (comment)
The text was updated successfully, but these errors were encountered: