-
Notifications
You must be signed in to change notification settings - Fork 33
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
Make storage adapter API return types consistent across Azure and GCP #26
Comments
@hannelita i'm not sure i totally understand this ... @shevron is this clear to you? If so, could you comment on what you think 😄 |
@hannelita are we talking about the GCP implementation of the streaming API or the built-in local storage one? Specifically about the code that doesn't work (I see it is GCP code) - what is expected to be returned there is the number of uploaded bytes or otherwise put, the size of the blob after all data has been uploaded. For this, you can just do: return blob.size I am not a GCP expert but I think this will work, or perhaps you may need to call If this is not what you meant, please clarify. Specifically "What's a good way to abstract over different providers and wsgi servers? Should we revisit the api?" is not clear to me - I find this API to be just the right level of abstract (get a file object, return the number of bytes uploaded as an int). If the problem is that gunicorn / heroku doesn't give you the size in bytes of |
As a side note, to the best of my understanding (again not a GCP / Heroku expect) you should not be using |
Also, we should not be using
|
It looks like the streaming API for GUnicorn on Heroku does not support the method tell(). ATM there is a workaround where I return the size of the stream; which is not fully compatible with the requested return type of put on the implementation of the provider. What's a good way to abstract over different providers and wsgi servers? Should we revisit the api?
Note: the code below is bad
The text was updated successfully, but these errors were encountered: