Using Plug.Upload in your changesets

Hello Everyone,

I am working on a small Phoenix/Ecto project. One of the features of this application is going to be that people can upload images. Right now I am using arc (and arc_ecto) to make the uploading procedure easier.

However, I want to store the dimensions and other metadata of the image that has been saved in the database as well, to make it nicer to display it in a gallery later.
I know there are multiple packages on Hex.pm that allow you to do this, such as fastimage, but these libraries work with a pathname to the file.

  • Exactly how can I make a library that takes a pathname consume a %Plug.Upload{} struct? I believe it contains a :path field, but I have been unable to build a %Plug.Upload{} manually to try it out. There is documentation of Plug.Upload, but it is rather short and uninformative (does the :path field include or exclude the actual filename itself, or only its folder? How do you make a %Plug.Upload{} struct manually?).
  • Related to this: How can you test file-uploading code? I am interested in doing both a feature-test, testing only if when you have a file if the dimensions are read and added to the changeset properly, and a full-stack test where a file is selected from the browser and it is then attempted to be uploaded.

Any help is greatly appreciated!

2 Likes

All right! I have since learned that the :path field is a path to a temporary file (including the filename itself). The :filename is the name used during uploading, which can be used to do (a weak form of!) MIME-checking, and possibly to store it in your app, etc.

I was able to call ImageMagick using the extracted :path. (Yes, this code should be cleaned up and get some documentation, but it’s a proof-of-concept.)

defmodule Cmd.Magick do
  def dimensions(file_path) do
    case System.cmd("identify", ["-format","%w %h", Path.expand(file_path)]) do
      {res, 0} ->
        [width, height] =
          res
          |> String.split
          |> Enum.map(&String.to_integer/1)
        %{width: width, height: height}
      {_other, _} ->
        raise ArgumentError
    end
  end
end

In my Phoenix 1.3 changeset function I’ve added a call to this function to the pipeline:

  def add_image_dimensions(changeset, attrs) do
    case attrs["image"] do
      %Plug.Upload{path: path, filename: filename} ->
        changeset
        |> cast(Cmd.Magick.dimensions(path), [:width, :height])
      path when is_binary(path) ->
        changeset
        |> cast(Cmd.Magick.dimensions(path), [:width, :height])
      _ ->
        changeset
    end
  end

This works!

What I am yet to figure out though, is how this code can be tested properly. Please help!

2 Likes

I’d hardcode a known file in the project somewhere, create a custom %Plug.Upload{} with the proper :path set, then just call it and test the output. :slight_smile:

2 Likes

IIRC, when I was working with file uploads in tests, I was creating Plug.Upload struct manually and passed it as regular parameter to get, post etc. macros in controller tests:

post conn, image_path(conn, :create), upload: %Plug.Upload{...}

EDIT: but of course the question is about changesets :blush: I think @OvermindDL1 is with the right approach.

3 Likes

Maybe validity of path + filename have to be checked also? I’m still struggling with the when and how of unit tests.

Be humble about what your unit tests can achieve,
unless you have an extrinsic requirements oracle for the
unit under test. Unit tests are unlikely to test more than one
trillionth of the functionality of any given method in a
reasonable testing cycle. Get over it. 

 If you write a test to cover as many possibilities as
possible you can dedicate a rack of machines to running the
tests 24 hours a day, 7 days a week, tracking the most
recent check-in. 

If you have a large unit test mass, evaluate the feedback
loops in your development process. Integrate code more
frequently; reduce the build and integration times; cut the
unit tests and go more for integration testing. 

The payoff in investment is higher in functional testing
than in unit testing: put your effort there. Functional testing
typically finds twice as many bugs as unit testing (see the
Capers Jones data a bit later in this column), even though
agile developers spend most of their time doing testing at
the unit level, including TDD.


2 Likes

I’m trying to test a file upload in my controller test. I’m using the approach you recommended:

but I keep getting the following error:

** (ArgumentError) structs expect an :id key when converting to_param or a custom 
implementation of the Phoenix.Param protocol (read Phoenix.Param docs for more information), 
got: %Plug.Upload{content_type: nil, filename: "fantasy_team_csv_table.csv", path: 
"test/fixtures/fantasy_team_csv_table.csv"}

Here is my code:

      file_path = "test/fixtures/fantasy_team_csv_table.csv"
      params = %{
        "table" => "FantasyTeam",
        "spreadsheet" => %Plug.Upload{path: file_path, filename: "fantasy_team_csv_table.csv"}
      }

      conn = post(conn, table_upload_path(conn, :create, table_upload: params))

I read the Phoenix.Params docs, but couldn’t figure out how to fix the error from the docs. Any ideas how to fix it? Thanks!

When you do it as post(conn, table_upload_path(conn, :create, table_upload: params)), you are passing the parameters as part of the query string, i.e. as part of the URL. You need to pass it as part of the post:

conn = post(conn, table_upload_path(conn, :create), table_upload: params)
3 Likes

Good to go after the update, thanks!