Skip to content
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

Introduce PatchType #158

Merged
merged 18 commits into from
Aug 21, 2017
Merged

Introduce PatchType #158

merged 18 commits into from
Aug 21, 2017

Conversation

glasserc
Copy link
Contributor

This is a proof-of-concept to demonstrate my opinion on the preferred way to address #125. I only updated patch_record so far, but adding others should be straightforward.

@leplatrem
Copy link
Contributor

I like the idea, go for it :) 👍

@glasserc glasserc mentioned this pull request Aug 16, 2017
Use this to distinguish different patch types, but only on
patch_record. Other patch_methods can come later if the technique
seems sane.
This makes it easier to write these kinds of PATCH methods.
This is analogous to patch_record, except that even if no ID is
present, we can still sometimes succeed because we have a _bucket_name
attribute.
Also, add a test, since one isn't present.
This argument in update_bucket, update_group, update_collection, and
update_record only existed to support the patch methods, as far as I
can tell, since it's completely untested. Since it no longer makes
sense to pass anything but ``PUT`` here, take it out.
Also, wrong patches should be TypeError, not ValueError.
Copy link
Contributor

@leplatrem leplatrem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we don't have sphinx/autodocs, don't forget to update the readme too ;)

README.rst Outdated

# It is also possible to manipulate bucket permissions (see later)
client.patch_bucket(id='payments', permissions={})
client.patch_bucket(id='payments', data=BasicPatch({'status': 'updated'}), permissions={})
Copy link
Contributor Author

@glasserc glasserc Aug 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure how to update this, but the given example wouldn't work with the new code. There's no tests for this kind of behavior either. If we intend for it to work even when you don't pass data at all, we should add tests for it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, if there is no test then it does not exist.

However, I believe this is a relevant use-case.

You can remove this from the README and open an issue to support it.

@glasserc
Copy link
Contributor Author

I just realized that this only supports patching data, but using e.g. JSON Patch on permissions is impossible with this API. However, using "merge patch" on permissions is currently impossible with any API; see Kinto/kinto#1322.

While we're here, make the pytest.raises assertions a little stricter.
Permissions have to be part of a patch_type because they are covered
by the same Content-Type.

This also means we can handle updating just permissions without
updating the data (fixes #161).
This verifies that it actually works with the server!
@glasserc glasserc merged commit 97c088a into Kinto:master Aug 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants