-
Notifications
You must be signed in to change notification settings - Fork 27
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
Migrate household
endpoints to new API structure
#2038
Conversation
household
endpoints to new API structure
Hey Mike, Thanks again for your review on this. Here's what I'd like to propose as a roadmap forward for both this PR and the PR migrating
|
I approve of your plan. I have added some more discussion above, but I don't want to block this work on it. |
…pdate tests to mirror that behavior
eb430a1
to
a3a78fc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some suggestions/nitts to simplify but nonblocking.
@mikesmit I'd like to make these changes an example moving forward, so I will go back and address your suggestions probably tomorrow, and would love to incorporate another round of changes before moving forward. In particular, I would actually like to refactor the error handlers, as they also require a double exception raising pattern within the route blueprints (happy to point out a line specifically if desired) and I think the structure could be better. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see quite what I was expecting. Requesting feedback on why that happened in the review (I.e. my feedback was unclear, my feedback was not good, we both agree on the direction but the change will happen later, etc.)
This failing test is (I'm guessing) driven by PolicyEngine/policyengine-core#321. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few notes for future consideration, but strongly suggest we move forward to unblock and iterate.
) | ||
if household is None: | ||
raise NotFound(f"Household #{household_id} not found.") | ||
else: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitt, style - suggest shipping and optionally changing later to unblock me (please:P ), but clean code suggests
if error:
raise Exception("...")
return success
instead of unnecessary else's or nesting.
If you don't have the book, this is an ok summary
country_id (str): The country ID. | ||
household_id (int): The household ID. | ||
""" | ||
print(f"Got request for household {household_id} in country {country_id}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussion, nonblocking -
Suggest this as an optimization after introducing "real" logging.
In the theme from yesterday of making our route functions as clean and simple as possible, logging is another function the framework should be able to do for us in many cases.
In this case the blueprint already defines what the path is, the names of the parameters, the method type and has the parsed values from the path, etc. so it should be possible to automate logging all the relevant "got a request" information.
- Reduces clutter/duplication
- reduces cases where we forget to manually add the log message
- makes it easy to add more detail later and get that for every method (I.e. maybe we want to log which user is making the request)
response.headers["X-Accel-Buffering"] = "no" | ||
# Set header to prevent buffering on Google App Engine deployment | ||
# (see https://cloud.google.com/appengine/docs/flexible/how-requests-are-handled?tab=python#x-accel-buffering) | ||
response.headers["X-Accel-Buffering"] = "no" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion, non-blocking again strongly suggest we don't iterate again over this, but I think this would be cleaner as a decorator like this. I don't think that is necessarily the right library so that would require a little research.
Suggest we look into how to set headers as part of integrating parsing/serialization automation.
@mikesmit Just merged. Thanks again for your help throughout this process. Hoping this unblocks your upcoming PR. |
Fixes #1988.
Fixes #2034.
This PR migrates the household endpoints to the new API structure.