I have an observer and I register an after_commit callback. How can I tell whether it was fired after create or update? I can tell an item was destroyed by asking item.destroyed? but #new_record? doesn't work since the item was saved.

I was going to solve it by adding after_create/after_update and do something like @action = :create inside and check the @action at after_commit, but it seems that the observer instance is a singleton and I might just override a value before it gets to the after_commit. So I solved it in an uglier way, storing the action in a map based on the item.id on after_create/update and checking its value on after_commit. Really ugly.

Is there any other way?

Update

As @tardate said, transaction_include_action? is a good indication, though it's a private method, and in an observer it should be accessed with #send.

class ProductScoreObserver < ActiveRecord::Observer
  observe :product

  def after_commit(product)
    if product.send(:transaction_include_action?, :destroy)
      ...

Unfortunately, the :on option does not work in observers.

Just make sure you test the hell of your observers (look for test_after_commit gem if you use use_transactional_fixtures) so when you upgrade to new Rails version you'll know if it still works.

(Tested on 3.2.9)

Update 2

Instead of Observers I now use ActiveSupport::Concern and after_commit :blah, on: :create works there.

tardate

I think transaction_include_action? is what you are after. It gives a reliable indication of the specific transaction in process (verified in 3.0.8).

Formally, it determines if a transaction included an action for :create, :update, or :destroy. Used in filtering callbacks.

class Item < ActiveRecord::Base
  after_commit lambda {    
    Rails.logger.info "transaction_include_action?(:create): #{transaction_include_action?(:create)}"
    Rails.logger.info "transaction_include_action?(:destroy): #{transaction_include_action?(:destroy)}"
    Rails.logger.info "transaction_include_action?(:update): #{transaction_include_action?(:update)}"
  }
end

Also of interest may be transaction_record_state which can be used to determine if a record was created or destroyed in a transaction. State should be one of :new_record or :destroyed.

Update for Rails 4

For those seeking to solve the problem in Rails 4, this method is now deprecated, you should use transaction_include_any_action? which accepts an array of actions.

Usage Example:

transaction_include_any_action?([:create])

I've learned today that you can do something like this:

after_commit :do_something, :on => :create

after_commit :do_something, :on => :update

Where do_something is the callback method you want to call on certain actions.

If you want to call the same callback for update and create, but not destroy, you can also use: after_commit :do_something, :if => :persisted?

It's really not documented well and I had a hard time Googling it. Luckily, I know a few brilliant people. Hope it helps!

You can solve by using two techniques.

The approach suggested by @nathanvda i.e. checking the created_at and updated_at. If they are same, the record is newly created, else its an update.
By using virtual attributes in the model. Steps are:
- Add a field in the model with the code attr_accessor newly_created
- Update the same in the before_create and before_update callbacks as
```
def before_create (record)
    record.newly_created = true
end

def before_update (record)
    record.newly_created = false
end
```

Based on leenasn idea, I created some modules that makes it possible to use after_commit_on_updateand after_commit_on_create callbacks: https://gist.github.com/2392664

Usage:

class User < ActiveRecord::Base
  include AfterCommitCallbacks
  after_commit_on_create :foo

  def foo
    puts "foo"
  end
end

class UserObserver < ActiveRecord::Observer
  def after_commit_on_create(user)
    puts "foo"
  end
end

Take a look at the test code: https://github.com/rails/rails/blob/master/activerecord/test/cases/transaction_callbacks_test.rb

There you can find:

after_commit(:on => :create)
after_commit(:on => :update)
after_commit(:on => :destroy)

and

after_rollback(:on => :create)
after_rollback(:on => :update)
after_rollback(:on => :destroy)

I'm curious to know why you couldn't move your after_commit logic into after_create and after_update. Is there some important state change that happens between the latter 2 calls and after_commit?

If your create and update handling has some overlapping logic, you could just have the latter 2 methods call a third method, passing in the action:

# Tip: on ruby 1.9 you can use __callee__ to get the current method name, so you don't have to hardcode :create and :update.
class WidgetObserver < ActiveRecord::Observer
  def after_create(rec)
    # create-specific logic here...
    handler(rec, :create)
    # create-specific logic here...
  end
  def after_update(rec)
    # update-specific logic here...
    handler(rec, :update)
    # update-specific logic here...
  end

  private
  def handler(rec, action)
    # overlapping logic
  end
end

If you still rather use after_commit, you can use thread variables. This won't leak memory as long as dead threads are allowed to be garbage-collected.

class WidgetObserver < ActiveRecord::Observer
  def after_create(rec)
    warn "observer: after_create"
    Thread.current[:widget_observer_action] = :create
  end

  def after_update(rec)
    warn "observer: after_update"
    Thread.current[:widget_observer_action] = :update
  end

  # this is needed because after_commit also runs for destroy's.
  def after_destroy(rec)
    warn "observer: after_destroy"
    Thread.current[:widget_observer_action] = :destroy
  end

  def after_commit(rec)
    action = Thread.current[:widget_observer_action]
    warn "observer: after_commit: #{action}"
  ensure
    Thread.current[:widget_observer_action] = nil
  end

  # isn't strictly necessary, but it's good practice to keep the variable in a proper state.
  def after_rollback(rec)
    Thread.current[:widget_observer_action] = nil
  end
end

I use the following code to determine whether it is a new record or not:

previous_changes[:id] && previous_changes[:id][0].nil?

It based on idea that a new record has default id equal to nil and then changes it on save. Of course id changing is not a common case, so in most cases the second condition can be omitted.

This is similar to your 1st approach but it only uses one method (before_save or before_validate to really be safe) and I don't see why this would override any value

class ItemObserver
  def before_validation(item) # or before_save
    @new_record = item.new_record?
  end

  def after_commit(item)
    @new_record ? do_this : do_that
  end
end

Update

This solution doesn't work because as stated by @eleano, ItemObserver is a Singleton, it has only one instance. So if 2 Item are saved at the same time @new_record could take its value from item_1 while after_commit is triggered by item_2. To overcome this problem there should be an item.id checking/mapping to "post-synchornize" the 2 callback methods : hackish.

You can change your event hook from after_commit to after_save, to capture all create and update events. You can then use: