196

I need to add timestamps (created_at & updated_at) to an existing table. I tried the following code but it didn't work.

class AddTimestampsToUser < ActiveRecord::Migration
    def change_table
        add_timestamps(:users)
    end
end
user664833
  • 18,397
  • 19
  • 91
  • 140
leonel
  • 10,106
  • 21
  • 85
  • 129

24 Answers24

238

The timestamp helper is only available in the create_table block. You can add these columns by specifying the column types manually:

class AddTimestampsToUser < ActiveRecord::Migration
  def change_table
    add_column :users, :created_at, :datetime, null: false
    add_column :users, :updated_at, :datetime, null: false
  end
end

While this does not have the same terse syntax as the add_timestamps method you have specified above, Rails will still treat these columns as timestamp columns, and update the values normally.

vkopio
  • 914
  • 1
  • 11
  • 28
Ben Simpson
  • 4,009
  • 1
  • 18
  • 10
  • 11
    This did not work for me in Rails 4. The below solution by "mu is too short" is working. – newUserNameHere Feb 06 '14 at 21:43
  • 24
    `rails g migration AddTimestampsToUser created_at:datetime updated_at:datetime` - a shortcut to generate the migration above. – Konstantine Kalbazov Aug 25 '14 at 17:32
  • 5
    Running this migration leads to error `PG::NotNullViolation: ERROR: column "created_at" contains null value` because my table already contains data which violates not null constraint. Any better way of doing this than removing the not null contraint at first and then adding it later ? – M. Habib Apr 24 '18 at 06:25
  • 1
    @M.Habib I don't think so, but [this answer](https://stackoverflow.com/a/43548750/1753903) encapsulates it all in one migration nicely. – littleforest Apr 30 '18 at 14:36
  • 1
    @M.Habib depends on what you think makes the most sense for the default value, you could do `add_column :users, :updated_at, :datetime, null: false, default: Time.zone.now`. `Time.zone.now` is just an example, you should use whatever value makes sense for your logic. – Delong Gao Jul 30 '19 at 23:46
  • It didn't worked for me on Rails 6... I used instead: `def change \n change_table :users do |t| \n t.timestamps \n end \n end` – Syph Jul 09 '20 at 09:13
96

Migrations are just two class methods (or instance methods in 3.1): up and down (and sometimes a change instance method in 3.1). You want your changes to go into the up method:

class AddTimestampsToUser < ActiveRecord::Migration
  def self.up # Or `def up` in 3.1
    change_table :users do |t|
      t.timestamps
    end
  end
  def self.down # Or `def down` in 3.1
    remove_column :users, :created_at
    remove_column :users, :updated_at
  end
end

If you're in 3.1 then you could also use change (thanks Dave):

class AddTimestampsToUser < ActiveRecord::Migration
  def change
    change_table(:users) { |t| t.timestamps }
  end
end

Perhaps you're confusing def change, def change_table, and change_table.

See the migration guide for further details.

mu is too short
  • 426,620
  • 70
  • 833
  • 800
  • 1
    (Well, there's the `change` method now, although in this case, not the issue :) – Dave Newton Sep 25 '11 at 01:59
  • @Dave: True enough, I went for generic to avoid the version issues but `change` is worth a mention so I'll add that too. – mu is too short Sep 25 '11 at 02:17
  • True mu but I have heard that that is really changing with 3.1 and the 'down' is really going away. Rails to figure out the down method automatically. Have you heard about that? – Michael Durrant Sep 25 '11 at 02:59
  • @Michael: I've been using MongoDB exclusively with the 3.1 app I'm working on so I haven't worked with 3.1 AR migrations. The docs indicate that everything is moving towards instance methods (for unknown reasons). – mu is too short Sep 25 '11 at 04:22
  • @MichaelDurrant, there are many scenarios that "change" doesn't cover right now, if up/down go away there will be some angry people :) (add an "unless" clause in your change migration to avoid migration collisions, and try rolling that back...) Even 3 years after you made this comment, I don't think it's changing. :) – frandroid Feb 14 '14 at 16:37
  • @RichPeck: Wow, how did you find the code under all that dust? – mu is too short Nov 11 '15 at 18:43
86

@user1899434's response picked up on the fact that an "existing" table here could mean a table with records already in it, records that you might not want to drop. So when you add timestamps with null: false, which is the default and often desirable, those existing records are all invalid.

But I think that answer can be improved upon, by combining the two steps into one migration, as well as using the more semantic add_timestamps method:

def change
  add_timestamps :projects, default: Time.zone.now
  change_column_default :projects, :created_at, nil
  change_column_default :projects, :updated_at, nil
end

You could substitute some other timestamp for DateTime.now, like if you wanted preexisting records to be created/updated at the dawn of time instead.

Nick Davies
  • 1,011
  • 8
  • 7
  • 2
    Amazing. Thank you! Just one note - `Time.zone.now` is what should be used if we want our code to obey the correct time zone. – John Gallagher Dec 15 '18 at 14:36
  • 7
    There is a problem with setting the default to `Time.zone.now` which is that it will return the Time instance that is created when the migration is run and just use that time as the default. New objects wont get a new Time instance. – Tovi Newman Apr 23 '19 at 19:35
  • This answer should be on the top! – Shankar Thyagarajan Jun 24 '22 at 09:00
83

Your original code is very close to right, you just need to use a different method name. If you're using Rails 3.1 or later, you need to define a change method instead of change_table:

class AddTimestampsToUser < ActiveRecord::Migration
  def change
    add_timestamps(:users)
  end
end

If you're using an older version you need to define up and down methods instead of change_table:

class AddTimestampsToUser < ActiveRecord::Migration
  def up
    add_timestamps(:users)
  end

  def down
    remove_timestamps(:users)
  end
end
georgebrock
  • 28,393
  • 13
  • 77
  • 72
40
class AddTimestampsToUser < ActiveRecord::Migration
  def change
    change_table :users do |t|
      t.timestamps
    end
  end
end

Available transformations are

change_table :table do |t|
  t.column
  t.index
  t.timestamps
  t.change
  t.change_default
  t.rename
  t.references
  t.belongs_to
  t.string
  t.text
  t.integer
  t.float
  t.decimal
  t.datetime
  t.timestamp
  t.time
  t.date
  t.binary
  t.boolean
  t.remove
  t.remove_references
  t.remove_belongs_to
  t.remove_index
  t.remove_timestamps
end

http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/Table.html

Dorian
  • 22,759
  • 8
  • 120
  • 116
Pradeep Sanjaya
  • 1,816
  • 1
  • 15
  • 23
14

Nick Davies answer is the most complete in terms of adding timestamp columns to a table with existing data. Its only downside is that it will raise ActiveRecord::IrreversibleMigration on a db:rollback.

It should be modified like so to work in both directions:

def change
  add_timestamps :campaigns, default: DateTime.now
  change_column_default :campaigns, :created_at, from: DateTime.now, to: nil
  change_column_default :campaigns, :updated_at, from: DateTime.now, to: nil
end
lightyrs
  • 2,809
  • 2
  • 29
  • 32
  • This didn't work exactly as written for me on Rails 4.2.7 (I think `change_column_default` doesn't support `from` and `to` in that version?), but I took this idea and created `up/down` methods instead of a single `change` method and it worked like a charm! – Gar Jan 24 '19 at 12:42
11

Using Time.current is a good style https://github.com/rubocop-hq/rails-style-guide#timenow

def change
  change_table :users do |t|
    t.timestamps default: Time.current
    t.change_default :created_at, from: Time.current, to: nil
    t.change_default :updated_at, from: Time.current, to: nil
  end
end

or

def change
  add_timestamps :users, default: Time.current
  change_column_default :users, :created_at, from: Time.current, to: nil
  change_column_default :users, :updated_at, from: Time.current, to: nil
end
shilovk
  • 11,718
  • 17
  • 75
  • 74
10

The issue with most of the answers here is that if you default to Time.zone.now all records will have the time that the migration was run as their default time, which is probably not what you want. In rails 5 you can instead use now(). This will set the timestamps for existing records as the time the migration was run, and as the start time of the commit transaction for newly inserted records.

class AddTimestampsToUsers < ActiveRecord::Migration def change add_timestamps :users, default: -> { 'now()' }, null: false end end

jlesse
  • 564
  • 5
  • 11
  • 1
    You probably don't want the timestamps for existing objects to be set to the time the migration is run. This would lead to misleading data/analytics. If the data isn't available from another source, then leaving it null is a better option. – bigtex777 Jun 14 '21 at 21:15
  • @bigtex777 you have a point. I think the decision to set time stamps for existing records just depends on your needs. Leaving them null might cause issues if you also add constraints on them. It also might make sense to set them to a date far in the past to signify that they were involved in this migration. Ideally you wouldn't get into a position where you are adding timestamps to a table after the tables creation. – jlesse Jun 30 '21 at 15:34
9
def change
  add_timestamps :table_name
end
FelixSFD
  • 6,052
  • 10
  • 43
  • 117
Ian Vaughan
  • 20,211
  • 13
  • 59
  • 79
8

I'm on rails 5.0 and none of these options worked.

The only thing that worked was using the type to be :timestamp and not :datetime

def change
    add_column :users, :created_at, :timestamp
    add_column :users, :updated_at, :timestamp
end
Vishnu Narang
  • 605
  • 8
  • 15
  • This is the answer I needed. Rspec tests were failing for me with datetime specified as the type (they wouldnt set the created_at by default) – BelgoCanadian Nov 15 '21 at 18:30
5

not sure when exactly this was introduced, but in rails 5.2.1 you can do this:

class AddTimestampsToMyTable < ActiveRecord::Migration[5.2]
  def change
    add_timestamps :my_table
  end
end

for more see "using the change method" in the active record migrations docs.

Reef Loretto
  • 61
  • 1
  • 6
  • I didn't make it work with Migration[5.1]; then I've changed the number to [5.2] and Rails told me that I could only use 5.1, 5.0 or 4.2. I've try with 5.0 with no success, then in 4.2 with success. – Is Ma Dec 10 '18 at 02:07
  • 1
    Old, I know, but if you have existing records add: `, null: true` after the `:my_table` – jomar May 03 '19 at 00:20
5

This seems like a clean solution in Rails 5.0.7 (discovered the change_column_null method):

def change
  add_timestamps :candidate_offices, default: nil, null: true
  change_column_null(:candidate_offices, :created_at, false, Time.zone.now)
  change_column_null(:candidate_offices, :created_at, false, Time.zone.now)
end
Wes Gamble
  • 777
  • 10
  • 29
4

A lot of answers here, but I'll post mine too because none of the previous ones really worked for me :)

As some have noted, #add_timestamps unfortunately adds the null: false restriction, which will cause old rows to be invalid because they don't have these values populated. Most answers here suggest that we set some default value (Time.zone.now), but I wouldn't like to do that because these default timestamps for old data will not be correct. I don't see the value in adding incorrect data to the table.

So my migration was simply:

class AddTimestampsToUser < ActiveRecord::Migration
  def change_table
    add_column :projects, :created_at, :datetime
    add_column :projects, :updated_at, :datetime
  end
end

No null: false, no other restrictions. Old rows will continue being valid with created_at as NULL, and update_at as NULL (until some update is performed to the row). New rows will have created_at and updated_at populated as expected.

Kostis
  • 1,593
  • 15
  • 16
2

I made a simple function that you can call to add to each table (assuming you have a existing database) the created_at and updated_at fields:

  # add created_at and updated_at to each table found.
  def add_datetime
    tables = ActiveRecord::Base.connection.tables
    tables.each do |t|
      ActiveRecord::Base.connection.add_timestamps t  
    end    
  end
Roger
  • 7,535
  • 5
  • 41
  • 63
2

add_timestamps(table_name, options = {}) public

Adds timestamps (created_at and updated_at) columns to table_name. Additional options (like null: false) are forwarded to #add_column.

class AddTimestampsToUsers < ActiveRecord::Migration
  def change
    add_timestamps(:users, null: false)
  end
end
almawhoob
  • 382
  • 3
  • 5
2

This is a simple one to add timestamp in existing table.

class AddTimeStampToCustomFieldMeatadata < ActiveRecord::Migration
  def change
    add_timestamps :custom_field_metadata
  end
end
Dinesh Vaitage
  • 2,983
  • 19
  • 16
2

In rails 6 (and possibly earlier) if you try to add timestamps to an existing table with records already present like this:

def change
  add_timestamps :table_name
end

you will get an error owing to the fact that add_timestamps by default declares the new colums as NOT NULL. You can work around this simply by adding null: true as an argument:

def change
  add_timestamps :table_name, null: true
end
KenB
  • 6,587
  • 2
  • 35
  • 31
1

The answers before seem right however I faced issues if my table already has entries.

I would get 'ERROR: column created_at contains null values'.

To fix, I used:

def up
  add_column :projects, :created_at, :datetime, default: nil, null: false
  add_column :projects, :updated_at, :datetime, default: nil, null: false
end

I then used the gem migration_data to add the time for current projects on the migration such as:

def data
  Project.update_all created_at: Time.now
end

Then all projects created after this migration will be correctly updated. Make sure the server is restarted too so that Rails ActiveRecord starts tracking the timestamps on the record.

Jai Chauhan
  • 4,035
  • 3
  • 36
  • 62
dbrody
  • 111
  • 1
  • 4
1

You can use a migration like this to add a created_at and updated_at columns to an existing table with existing records. This migration sets the created_at and updated_at fields of existing records to the current date time.

For the sake of this example say the table name is users and the model name is User

class AddTimestampsToTcmOrders < ActiveRecord::Migration[6.0]
  def up
    # Add timestamps to the users table with null as true cause there are existing records
    add_timestamps(:users, null: true)

    # Update existing records with non-nil timestamp values
    User.update_all(created_at: DateTime.now, updated_at: DateTime.now)

    # change columns so they can't be nil
    change_column(:users, :updated_at, :datetime, null: false, precision: 6)
    change_column(:users, :created_at, :datetime, null: false, precision: 6)
  end

  def down
    remove_column :users, :updated_at
    remove_column :users, :created_at
  end
end
CBK
  • 141
  • 1
  • 6
0

For those who don't use Rails but do use activerecord, the following also adds a column to an existing model, example is for an integer field.

ActiveRecord::Schema.define do
  change_table 'MYTABLE' do |table|
    add_column(:mytable, :my_field_name, :integer)
  end
end
peter
  • 41,770
  • 5
  • 64
  • 108
0

It's change, not change_table for Rails 4.2:

class AddTimestampsToUsers < ActiveRecord::Migration
  def change
    add_timestamps(:users)
  end
end
Igor
  • 2,834
  • 2
  • 26
  • 44
0

I am using Rails 6.0.2.1 & Ruby 2.6.5. I tried many solutions but issue I was facing was, if default time set, the time when migration is run, was being set to default. So when creating new record, same time was set in timestamps. If no default given, it was throwing error for null value present error for already present records. Finally searched chatgpt and found below solution and it worked for me.

class AddTimestampsToTableName < ActiveRecord::Migration[6.0] 
  def change
    add_timestamps :table_name, null: false, default: -> { 'CURRENT_TIMESTAMP' }
  end
end
-1

I personally used the following, and it updated all previous records with the current time/date:

add_column :<table>, :created_at, :datetime, default: Time.zone.now, null: false
add_column :<table>, :updated_at, :datetime, default: Time.zone.now, null: false
Simple Lime
  • 10,790
  • 2
  • 17
  • 32
Jaime
  • 1
  • 1
-1

I ran into the same issue on Rails 5 trying to use

change_table :my_table do |t|
    t.timestamps
end

I was able to add the timestamp columns manually with the following:

change_table :my_table do |t|
    t.datetime :created_at, null: false, default: DateTime.now
    t.datetime :updated_at, null: false, default: DateTime.now
end
  • 1
    won't this always set the default value with the time at the moment the migration was run ? (so not really a dynamic timestamp handled by the DB) – Guillaume Petit Oct 16 '19 at 09:12
  • for the records that already exist in your db, yes, it will set the created_at and updated_at to the datetime the migration was run. Without having those values beforehand though, idk how else you'd initialize those values. EDIT: It would just be considered the beginning of that row's history – Andres Rosales Oct 17 '19 at 15:22