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

if_not_exists for batch.create_* doesn't work #73

Open
Natim opened this issue Jun 1, 2016 · 2 comments
Open

if_not_exists for batch.create_* doesn't work #73

Natim opened this issue Jun 1, 2016 · 2 comments
Labels
enhancement stale For marking issues as stale. Labeled issues will be closed soon if label is not removed.

Comments

@Natim
Copy link
Member

Natim commented Jun 1, 2016

The if_not_exists behavior doesn't ignore the 412 if they happen in a batch.

@Natim
Copy link
Member Author

Natim commented Jun 1, 2016

A work-around is to use safe=False for now but it is not exactly the same behavior.

@glasserc
Copy link
Contributor

This is going to be pretty tricky. The current way if_not_exists is implemented is:

  • Make the request with if-none-match
  • If the request succeeded, return the response.
  • If you got a 412, then it existed. The real value was returned, but not its permissions. Fetch its permissions.

For this to work in a batch, the request would have to enqueue some kind of post-request processing, and that processing might need to issue another batch of requests. Tying all of that together seems complicated and error-prone.

I'm trying to think if there's a larger solution here and I'm not really seeing one. Even if we had something like Futures to tie the results of a batch to the requests, we'd still need some kind of after-response-with-potentially-new-batch mechanism, which is ugly. There's also the fact that what we have right now isn't really re-entrant. It's possible that the first request gets a 412, but the conflicting record gets deleted before the second request, which gets a 404. Right now we don't handle this at all, but we could imagine the second request re-triggering the first request, which could retrigger the second request, on and on forever.

I feel like the right solution here is to change the server to return the permissions as well as the data on a 412. If we did that, then we would never need a follow-up request and we could just add some kind of post-processing that transformed 412 responses. But I'm not sure this is extensible. Is it possible for Kinto plugins to add other fields to record responses, but not to 412 responses?

@alexcottner alexcottner added the stale For marking issues as stale. Labeled issues will be closed soon if label is not removed. label Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stale For marking issues as stale. Labeled issues will be closed soon if label is not removed.
Projects
None yet
Development

No branches or pull requests

3 participants