-
Notifications
You must be signed in to change notification settings - Fork 26
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
[APIC-306] Fixed a bug in parsing responses that included "update" as a key #410
Conversation
dab3d2e
to
11b5c85
Compare
…., in column information from `client.tables.get(...)`)
11b5c85
to
4b1992c
Compare
@@ -174,3 +174,15 @@ def test_convert_data_type_civis_list(): | |||
assert isinstance(data[0], Response) | |||
assert data[0]['foo'] == 'bar' | |||
assert data[0].headers == {'header': 'val'} | |||
|
|||
|
|||
def test_parse_column_names(): |
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.
this test would fail before
|
||
self.update(self_updates) | ||
# Update self.__dict__ at the end to avoid replacing the update method. | ||
self.__dict__.update(self_updates) |
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.
so the issue is that the update
key was overwriting the dictionary
update
method?
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.
yeah, and then the next update
call would fail.
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.
LGTM
This fixes a bug where a column named "update" would cause response parsing to fail for
/tables
endpoints.The
civis.response.Response
provides convenient access to response attributes (e.g.,response.attrib
as opposed toresponse['attrib']
). In retrospect, perhaps it'd have been better not to have that functionality recur all the way down the response structure (or at least not into user-provided table info), but that ship has sailed, and in order to minimize breaking changes, this PR should preserve the existing functionality and avoid the bug.