-
Notifications
You must be signed in to change notification settings - Fork 1
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
Eatyourpeas/issue20 #22
base: live
Are you sure you want to change the base?
Conversation
begin work on viewsets and serializers add boundaries
add gis to dockerfile
fix migration
add ord update function wire up to celery beat
note not all organisations are in the database
-currently import error
update url paths
refactor data_zone_code to code schema broken
fix openapi.json
fix imd and organisation viewsets and serializers return organisation by ods_code
note in previous commit also added django-rest-framework-gis to requirements
tidy messaging and urls
add new nhsenglandregionwithenstedorganisation serializer update urls
add openapi examples and urls
refactor migrations
Slightly old screen shot as the London Boroughs are in there also.
Merging this would close #20 |
Discussion with @pacharanero and @dc2007git and Keith Blackwood. Initial step though is to:
|
remove associated views/serializer/routes dockerize - remove celery/beat/flower remove postgis and postgis container add sqlite - commit db to repo change ports to 8005 for django, 8006 for docs
add tests
@eatyourpeas looking forward to the pairing session on this! Just a small question after having a look through the code myself, in general_functions/ods_update.py, in line 148 and 149, I noticed that trust.town and trust.postcode are set to print statements. Since print returns None, would this not set those 2 variables equal to None? |
Thanks @dc2007git sorry yes those are debug statements. That set of functions ultimately will hit the ORD API for any published updates to organisation or trust structure, will search for a matching organisation in our database and update the record and bump the date. The workflow is not yet complete so not for primetime. |
Just a general FYI - seeing a lot of |
Also should this be PR'ing into |
That is a good point @anchit-chandran yes, should really be into development. We don't really have a work flow like that for this repo but am open to setting this up. |
Pull Request Summary
s
folder to uses/up
.task.py
in project root as an async functionpoll_ORD_spineservices_update_organisations_and_trusts()
, according to a new beat schedule insettings.py
:The code for making the API call and updating the models with any newly published changes in the ODS can be found in
general_functions/ods_update.py
3. Rename project and application as deprivation scores is now not the only service provided. This is done according to DRF principles - where the application sits within the project folder, not at the same level
4. Introduce seeding of all Organisations/Trusts/Local Health Boards/NHS England Regions and Countries, as well as OPENUK Networks (childhood epilepsy network) and Paediatric Diabetes Units. Includes boundary files from ONS and seeding of the same. This is almost identical to E12.
5. Move seeding of existing Index of Multiple Deprivation data and dependencies into the migrations.
6. Reorganise and refactor all serialisers, views and URLs and cull to include only essential endpoints. These are all refactored with DRF-spectacular, to OpenAPI 3.0 spec.
7. Add OpenAPI examples to all end points. All endpoints closed to GET request only.
7. Add DRF-GIS library to allow GIS data to be included
8. Rewrite documentation, borrowing heavily from E12 for legal/clinical safety aspects. Remove previously written endpoints and replace with OpenAPI spec.
Note this does not include tests which are in a parallel PR to the currently live branch. That branch (#21) arguably should be merged first as those tests need including in this.
Does not include
Tests of the API Spec and endpoints. These should be the next piece of work and should be fairly easy now that this work is done, and tests of the IMD endpoints (which are the most production critical) are already complete in #21.
Implications
The IMD calculation endpoints have changed:
index_of_multiple_deprivation/extended and
index_of_multiple_deprivation/quantile
The code within the functions as has not changed, through the quantile calculation has been moved into a general_function and moved out of the seeding.
This will have implications for the Epilepsy12 so the endpoints will need refactoring there also.
Dockerising the RCPCH Census Platform will mean it will be possible to deprecate the Azure database as a service which currently is used in live.