Waffle GCS v0.1.0 Waffle.Storage.Google.Util View Source
A collection of utility functions.
Link to this section Summary
Functions
Builds a Tesla.Multipart
structure containing two parts: a binary payload
and metadata about the binary payload. The metadata
argument must be JSON
encodable, i.e. it must succeed when passed to Poison.encode!/1
.
Attempts to return a value from a given options list, using the application
configs as a back-up. The application (used in Application.get_env/3
) is
assumed to be :waffle
.
If the given string does not already start with a forward slash, this function will prepend one and return the result.
For some reason, the Elixir library for Google Cloud Storage DOES NOT support binary data uploads. Their code always assumes that a path to a file is being passed to it and constructs the request as such. More infuriating is that Tesla, the HTTP library being used to make these requests, converts file paths to binary streams anyway, so adding the data to a temporary file would add additional steps. Specifically, we'd be doing the following
Accepts four forms of variables
Link to this section Functions
build_binary_body(metadata, bin)
View Sourcebuild_binary_body(GoogleApi.Storage.V1.Model.Object.t(), String.t()) :: Tesla.Multipart.t()
Builds a Tesla.Multipart
structure containing two parts: a binary payload
and metadata about the binary payload. The metadata
argument must be JSON
encodable, i.e. it must succeed when passed to Poison.encode!/1
.
Attempts to return a value from a given options list, using the application
configs as a back-up. The application (used in Application.get_env/3
) is
assumed to be :waffle
.
This assumes that the application environment is set using waffle
as the
application name.
If the value is not found in any of those location, an optional default value can be returned.
If the given string does not already start with a forward slash, this function will prepend one and return the result.
Examples
> prepend_slash("some/path")
"/some/path"
> prepend_slash("/im/good")
"/im/good"
storage_objects_insert_binary(connection, bucket, metadata, bin)
View Sourcestorage_objects_insert_binary( Tesla.Env.client(), String.t(), GoogleApi.Storage.V1.Model.Object.t(), String.t() ) :: Waffle.Storage.Google.CloudStorage.object_or_error()
For some reason, the Elixir library for Google Cloud Storage DOES NOT support binary data uploads. Their code always assumes that a path to a file is being passed to it and constructs the request as such. More infuriating is that Tesla, the HTTP library being used to make these requests, converts file paths to binary streams anyway, so adding the data to a temporary file would add additional steps. Specifically, we'd be doing the following:
- Receive binary data (maybe from a stream).
- Write the binary data to a temporary file.
- Tesla opens the temporary file as a stream.
- The request is made.
- Delete the temporary file.
Internally, Google relies solely on Tesla.Multipart.add_file/3
which creates
a stream from the given filepath and then calls
Tesla.Multipart.add_file_content/3
. I have bypassed this step by creating a
multipart struct manually, adding the binary data with add_file_content
, and
setting it to the request body. Fun fact: if you have no file
param and your
body
param has a single entry of {:body, _}
, the Google connection will
use whatever the value is verbatim. We take advantage of that weird fact to
bypass their custom build_body
logic.
Accepts four forms of variables:
- The tuple
{:system, key}
, which usesSystem.get_env/1
. - The tuple
{:app, key}
, which usesApplication.get_env/2
. - The tuple
{:app, app, key}
, which useesApplication.get_env/2
. - Anything else which is returned as-is.
In the second form ({:app, key}
), the application is assumed to be :waffle
although this can be overriden using the third form ({:app, app, key}
).