feat: Manage soil intervals on backend #1100
Conversation
Function is responsible for deleting and creating site intervals when the user performs the following options: 1) Updates project depth preset 2) Adds site to project / creates site in project 3) Transfers sites to project It needs to be used in the GraphQL mutations now
There was a problem hiding this comment.
- Please have @shrouxm review as well.
- We cannot rely on soft_delete-d items being available, as these records get removed periodically.
| intervals = [] | ||
| for site in sites: | ||
| if not hasattr(site, "soil_data"): | ||
| # Not going to create an interval if soil_data doesn't exist |
There was a problem hiding this comment.
| # Not going to create an interval if soil_data doesn't exist | |
| # Do not create an interval if soil_data doesn't exist |
There was a problem hiding this comment.
i haven't had time to think through all the possibilities yet to see if there's any bugs in the implementation, but i am very nervous about the amount of backend data chasing there is with this approach. i'm trying to understand the problem a bit more, in the original thread you asked the question:
"This is what is currently causing me a headache - say there is a project level interval. What do we do when the user activates the allow input switch? The project intervals aren't saved on the backend / don't have the input information if they are."
reading through the code for the update depth interval mutation again, it seems like the answer to that question would be "a depth interval object will be created on demand to store the configuration". is that wrong, & if not is there some other issue that that creates down the line?
also, re this question from this PR:
it's not obvious to me how to differentiate between "inactive" intervals linked to the old preset, and "active" intervals linked to the new preset.
I think one implementation could be change the object manager that the soil depth interval uses. It would automatically filter out any intervals that don't match the current preset in any database query.
we could implement that logic clientside as well
maybe we should do a quick call to think through this i'm feeling very 😵💫 about it
Co-authored-by: Paul Schreiber <[email protected]>
david-code
force-pushed
the
feat/manage-soil-intervals
branch
from
2434c8a to
36397e6
Compare
Description
This PR ended up doing a few things:
It's basically a grab bag of fixes that I needed in order to get the frontend to work.
Checklist
Related Issues
Related to techmatters/terraso-mobile-client#502, but will still need frontend work