Migrating in Phoenix

Phoenix Migration

This is part of the series on Phoenix, taking you from noob to !noob. Here are the list of posts so far:

1. Intro
2. Scaffolding

Today we will look at the migration file that's produced from the scaffolding we performed last time.

Migration File

defmodule PhoenixLibrary.Repo.Migrations.CreateBook do
  use Ecto.Migration

  def change do
    create table(:books) do
      add :title, :string
      add :author, :string
      add :description, :text

      timestamps()
    end

  end
end

At the end of generating the scaffold, we created the file above - priv/repo/migrations/20161014160805_create_book.exs. We are going to take a quick look at it and figure out what it's doing.

In the Rails world, we would have gotten a file like this:

class CreateBooks < ActiveRecord::Migration[5.0]
  def change
    create_table :books do |t|
      t.string :title
      t.string :author
      t.text :description

      t.timestamps
    end
  end
end

What's great is that the same basic thing that we are doing in Rails we are doing in Phoenix. In the Rails version we are creating a class to capture us creating a new books table and in the Phoenix version, we aren't creating a class, but instead creating a module.

In the Rails world, we are extending from ActiveRecord, but in Phoenix we are using helpers from Ecto.Migration. The important method that we are defining is the `change` method. This allows us to go forwards or backwards in our migration, to either create or tear down the table.

# Rails is rake db:migrate
mix ecto.migrate         # Runs migrations up on a repo

# Rails is rake db:rollback
mix ecto.rollback        # Reverts migrations down on a repo

The change method in both worlds take two arguments, a symbol representing the table we are going to create and a block where we create the actual columns in the table. In Rails we get a helper object that we can use to call functions where as in Phoenix we don't have/need a helper and can just call the add function passing in the name of the column and the type. And of course in Phoenix we call the timestamps function to create the created_at and updated_at column. But, in Rails we call the timestamps method on the helper.

In the future, we will dig into the models that are created from the scaffold command.

Phoenix Scaffolding

Phoenix, Let's Build

Welcome to the second installment of our Phoenix walkthrough. Last time we set up Phoenix, our database and saw our default 'Welcome' page for our dummy library application.

This week we will use some more generators and create our first model, views, and controller. Since this will be a library application, the most obvious choice of our first model should be a `book`.

Generate Scaffold

# mix [generator name] [model name] [table name] [attribute name : attribute type]
mix phoenix.gen.html Book books title:string author:string description:text

# in rails we do
#   rails generate scaffold Book title:string author:string description:text

There are a few key differences between the two, although they are very similar:

• mix: it's the rake/rails of the elixir world.
• phoenix.gen.html: this is the generator to use. remember that generators are just ordinary elixir scripts. also notice the `html` suffix which uses the script to generate html (as opposed to json -> phoenix.gen.json).
• Book: this is the model name. notice the upper case. all models are uppercased.
• books: this is an interesting distinction vs the rails world. WE NAME THE TABLE OURSELVES.
  in rails the name of the table is automatically made to be the pluralized name of the model, like Book (model name) -> books (table name).
  but English is a quirky language and you cannot always just add `s` to the end of the word, like child to children. so there is some complication in how rails needs to figure out to pluralize you model name.
  this is the first example of some bloat that Phoenix does away with, instead of trying to figure out how to pluralize your model name, Phoenix just defers to you, the developer, to name the table.
• attributes: this is exactly the same as rails. except in Phoenix, if we omit the type, it defaults to `string`.

➜  phoenix_library git:(master) mix phoenix.gen.html Book books title author description:text

* creating web/controllers/book_controller.ex
* creating web/templates/book/edit.html.eex
* creating web/templates/book/form.html.eex
* creating web/templates/book/index.html.eex
* creating web/templates/book/new.html.eex
* creating web/templates/book/show.html.eex
* creating web/views/book_view.ex
* creating test/controllers/book_controller_test.exs
* creating web/models/book.ex
* creating test/models/book_test.exs
* creating priv/repo/migrations/20161014160805_create_book.exs

Add the resource to your browser scope in web/router.ex:

    resources "/books", BookController

Remember to update your repository by running migrations:

    $ mix ecto.migrate

Look at all the nice things that are generated. This is very similar to scaffold generation. You can see theres:

• controller: book_controller
• templates: index, show, new, edit, form
• views: book_view
• model: book
• tests: book_controller, book
• migration

We will eventually tackle them all, but not right now. Let's go ahead and follow the prompts. Open up web/router.ex and add in the new route to our books resource. Notice this distinction from Rails also. In Rails, this is done for you.

  scope "/", PhoenixLibrary do
    pipe_through :browser # Use the default browser stack

    get "/", PageController, :index

    # added this line here
    resources "/books", BookController
  end

Next run `rake db:migrate`...I mean `mix ecto.migrate`. :)

➜  phoenix_library git:(master) ✗ mix ecto.migrate
Compiling 9 files (.ex)
Generated phoenix_library app

04:42:58.436 [info]  == Running PhoenixLibrary.Repo.Migrations.CreateBook.change/0 forward

04:42:58.436 [info]  create table books

04:42:58.456 [info]  == Migrated in 0.0s

Now start the server and check out your changes!

➜  phoenix_library git:(master) ✗ mix phoenix.server
Compiling 8 files (.ex)
[info] Running PhoenixLibrary.Endpoint with Cowboy using http://localhost:4000
21 Oct 04:46:52 - info: compiled 6 files into 2 files, copied 3 in 2.1 sec

Don't forget to hit the new route -> http://localhost:4000/books. Alright, that's it for now. Next time we'll talk about the model and migration.

The Rise of the Phoenix

Phoenix For the Rails People

I've been doing Rails for a long while now. Before Rails I was doing Enterprise Java but then my mentor at the time showed me this cool framework that took convention over configuration seriously and allowed really powerful things to be built quickly and easily. I was amazed and have been using tools like this ever since.

But the big argument against Rails is that it doesn't scale and is a bit bloated. Also there is a bit of a shift towards using more functional approaches. Enter my fascination with Elixir and Phoenix.

The next series of posts will be all about me learning Phoenix, but with a slant towards comparing and contrasting it against Rails. So strap in and take the journey with me.

I learn by doing, so I'll be building my normal 'hello world' type application, which is a library application. I used to spend a lot of time in libraries as a kid so I think thats the reason my default application is usually an application to track and catalog books. So let's get started.

Prerequisites

Before getting started, you will need to install a few things. I'll assume you are on mac and have homebrew installed. First is postgres.

brew update
brew install postgres
createuser -P -s -e root
# then setup your root user or whatever you want your user to be called

Next install Elixir and mix.

brew install elixir 
mix local.hex

Now install Phoenix.

mix archive.install https://github.com/phoenixframework/archives/raw/master/phoenix_new.ez

Now we are ready to start building our app.

New Application

We will start first by creating the application. In rails we'd do something like:

rails new rails_library --database=postgresql

but in Phoenix we do:

mix phoenix.new phoenix_library

First thing to note here is `mix`, which is Elixir's build tool. Already a little different than the rails command. Also notice we run `phoenix.new` which really is nothing more than just a script that we run with mix. Lastly we pass it the name of the new project. Also notice that postgres is the default, so we don't have to tell it that we will be using it.

This command created a bunch of folders full of stuff, which we will get to as we need....which is right now. :) Open up the `dev.exs` file in the config dir and modify it as necessary to use the correct username and password to connect to your locally running postgres instance. Go ahead and do that for the `test.exs` file as well.

With that done, we can set up your db schemas by running:

mix ecto.create

# in rails we would do `rake db:create`

Very similar to rails, but instead of the rake command we use our Elixir build tool called mix, and we run the ecto.create script. Ecto is the database wrapper, so we will be seeing `Ecto` a lot.

The last thing we will do in our very gentle intro is to start the Phoenix server.

mix phoenix.server

# in rails we would do `rails server`

Then navigate to localhost:4000 and you will see the dummy page.

Next time we will be creating some models, views, and controllers. Until then!