BDMS 170: allow well to have multiple purposes and casing materials#186
Conversation
jacob-a-brown
requested review from
TylerAdamMartinez,
chasetmartin,
jirhiker and
ksmuczynski
Codecov Report❌ Patch coverage is
|
|
|
||
| verify_thing_type_correspondence(thing, request) | ||
|
|
||
| data = payload.model_dump(exclude_unset=True) |
There was a problem hiding this comment.
I don't think we have a business use case for this currently. Lets leave it out for now
There was a problem hiding this comment.
everything else is looking good!
There was a problem hiding this comment.
Remove the ability to update well_purpose?
There was a problem hiding this comment.
yes. updating the well_purpose and well_casing_materials should follow the same CRUD structure as all other models. just because its not in the patch payload doesn't mean it should be deleted
There was a problem hiding this comment.
It's only deleting the previous records and creating new ones if well_purposes is in the payload (same with well_casing_materials); if well_purposes is not in the payload nothing happens. Since a well may have many purposes, if the user changes the purposes from ["Domestic", "Irrigation"] to ["Observation"] I don't know which one to change. So rather than change an existing record I remove the existing ones and create new ones for the new purposes.
There was a problem hiding this comment.
Rather than have this handled in the generic patch_thing function, though, I can handle these cases at the PATCH /thing/water-well/{thing_id} endpoint. That'll keep the code much cleaner and separate concerns
There was a problem hiding this comment.
Which, if we want to proceed with that updating method (deletion/insertion), this seems to make a lot more sense for code usability, maintainability, and readability
| db_table, field_name = WELL_CHILD_MODEL_MAP[child_table] | ||
| child_table_data = payload.model_dump(exclude_unset=True).pop( | ||
| child_table, None | ||
| for descriptor_table in WELL_DESCRIPTOR_MODEL_MAP.keys(): |
There was a problem hiding this comment.
for key,value in WELL_DESCRIPTOR_MODEL_MAP.items():
3 participants
Why
This PR addresses the following problem / context:
How
Implementation summary - the following was changed / added / removed:
WellPurposeandWellCasingMaterialtables and related them tothingWellResponseschema just returns a list of purposes and materials, not the full objectsNotes
Any special considerations, workarounds, or follow-up work to note?
patch_thingto remove associated purposes/materials and add new ones if the user wants to edit them (since there's no direct CRUD access to those tables). Is this the right way to proceed?