-
Notifications
You must be signed in to change notification settings - Fork 44
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
Validator improvements #515
Conversation
7acf4c4
to
6020edc
Compare
fbcfd4a
to
b5a073e
Compare
Codecov Report
@@ Coverage Diff @@
## master #515 +/- ##
==========================================
+ Coverage 91.51% 91.67% +0.15%
==========================================
Files 62 62
Lines 3135 3182 +47
==========================================
+ Hits 2869 2917 +48
+ Misses 266 265 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
b5a073e
to
4ede5b2
Compare
2f3c1a4
to
5615abc
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.
One comment, otherwise this looks good.
new_entry = entry.dict(exclude_unset=False) | ||
for field in ("relationships", "links", "meta", "type", "id"): | ||
if field in new_entry and new_entry[field] is None: | ||
del new_entry[field] |
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.
Can you not use the exclude_none
parameter here?
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.
Unfortunately not: the problem is that we want to include None
values from all entry properties, but not from these top-level response fields. I'm sure there is a neater way of doing this, but I'd rather be explicit for now as its hopefully only a temporary "fix" before it can be dealt with properly in #504.
I'll give @CasperWA until tomorrow to have a look if he wants to, if not I'll merge in the morning. |
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.
Cheers @ml-evs !
I'm having a bit of trouble penetrating all of your changes here, but it seems all right.
I've put in a few comments, nothing serious I believe.
Yeah, this one got a bit out of hand, but think it would have been more annoying as multiple PRs. I'll rebase this one into a few feature commits to maintain some kind of structure. |
fc63615
to
a70b0d2
Compare
- when getting a "chosen entry" - when making a request of SHOULD/OPTIONAL fields of entry endpoints - improved error handling of chosen_entry and empty endpoints - Until None valued response fields are applied based on the entry schema and the response fields query parameter, return all unset fields with exclude_unset=False when handling response fields (should be dealt with in #504)
a70b0d2
to
9681f86
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.
Cheers @ml-evs 👍
Closes #514, supercedes #513
Blocked by #503.
This PR fixes the above problems, and tidies some of the
@test_case
decorator into theValidatorResults
class.ValidatorResults
&test_case
chosen_entry
query (closes 'Chosen entry had no value for ...' when property is not requested #514)exclude_unset
when handling query params. This will need a proper treatment based on the actual requested fields, pending Responses for unknown fields #504...