Ecto: Using timestamps(updated_at: false) in a migration does not stop Ecto from adding this column to the table

[angelikatyborska]

Environment

• Elixir version: 1.3.2
• Database and version: PostgreSQL 9.5.3
• Ecto version (mix deps): 2.0.4
• Database adapter and version (mix deps): Postgrex 0.11.2
• Operating system: OS X 10.11.6
  

  Current behavior

Having defined this migration:

defmodule MyApp.AddSessionsTable do
  use Ecto.Migration

  def change do
    create table(:sessions) do
      add :game_id, :string

      timestamps(inserted_at: :created_at, updated_at: false)
    end
  end
end

When I run mix ecto.create && mix ecto.migrate, a table with both created_at and updated_at columns gets created:

# \d+ sessions
                                                         Table "public.sessions"
   Column   |            Type             |                       Modifiers                       | Storage  | Stats target | Description
------------+-----------------------------+-------------------------------------------------------+----------+--------------+-------------
 id         | integer                     | not null default nextval('sessions_id_seq'::regclass) | plain    |              |
 game_id    | character varying(255)      |                                                       | extended |              |
 created_at | timestamp without time zone | not null                                              | plain    |              |
 updated_at | timestamp without time zone | not null                                              | plain    |              |
Indexes:
    "sessions_pkey" PRIMARY KEY, btree (id)

Expected behavior

From my understanding of the docs, I would expect not to have a updated_at column at all when passing the option updated_at: false to timestamps.

[michalmuskala]

The migration timestamps macro does not support disabling fields in this way, it's not documented that it does: https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/migration.ex#L626-L637

That said, I believe we should follow the rule of least surprise and have feature parity between migrations and schemas. In order to do that we need two things:

• allow passing false to disable a timestamp field
• add option type for passing the field type.