Rails 3: Как определить действие after_commit у наблюдателей? (Создание / обновление / уничтожить)

Question

У меня есть наблюдатель, и я регистрирую обратный вызов after_commit.Как я могу сказать, был ли он запущен после создания или обновления?Я могу сказать, что предмет был уничтожен, спросив item.destroyed?, но #new_record? не работает, так как предмет был сохранен.

Я собирался решить его, добавив after_create / after_update и что-то сделатькак @action = :create внутри и проверьте @action в after_commit, но кажется, что экземпляр наблюдателя является одиночным, и я мог бы просто переопределить значение, прежде чем оно достигнет after_commit.Так что я решил ее более уродливо, сохранив действие на карте на основе item.id в after_create / update и проверив его значение в after_commit.Действительно ужасно.

Есть ли другой способ?

Обновление

Как сказал @tardate, transaction_include_action? является хорошим показателем, хотя это частный метод, и вНаблюдатель должен получить к нему доступ #send.

class ProductScoreObserver < ActiveRecord::Observer
  observe :product

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

К сожалению, опция :on не работает в наблюдателях.

Просто убедитесь, что вы проверили ад своих наблюдателей (посмотритедля test_after_commit gem, если вы используете use_transactional_fixtures), поэтому при обновлении до новой версии Rails вы узнаете, работает ли он по-прежнему.

(протестировано на 3.2.9)

Обновление 2

Вместо Наблюдателей я теперь использую ActiveSupport :: Concern и after_commit :blah, on: :create там работает.

Answer 1

Сегодня я узнал, что вы можете сделать что-то вроде этого:

after_commit :do_something, :on => :create

after_commit :do_something, :on => :update

Где do_something - это метод обратного вызова, который вы хотите вызвать для определенных действий.

Если вы хотите вызвать тот же обратный вызов для update и create , но не destroy , вы также можете использовать: after_commit :do_something, :if => :persisted?

Это действительно плохо документировано, и мне было трудно найти его в Google. К счастью, я знаю несколько блестящих людей. Надеюсь, это поможет!

Answer 2

Я думаю, action_include_action? - это то, что вам нужно. Это дает надежное указание на конкретную транзакцию в процессе (проверено в 3.0.8).

Формально он определяет, включала ли транзакция действие для: create,: update или: destroy. Используется при фильтрации обратных вызовов.

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

Также может представлять интерес action_record_state , который можно использовать для определения, была ли запись создана или уничтожена в транзакции. Состояние должно быть одним из: new_record или: destroy.

Обновление для Rails 4

Для тех, кто пытается решить проблему в Rails 4, этот метод устарел, вы должны использовать transaction_include_any_action?, который принимает array действий.

Пример использования:

transaction_include_any_action?([:create])

Answer 3

Вы можете решить, используя две техники.

• Подход, предложенный @nathanvda, т. Е. Проверка create_at и updated_at.Если они совпадают, запись создается заново, в противном случае это обновление.

• Использование виртуальных атрибутов в модели.Шаги:

  • Добавить поле в модели с кодом attr_accessor newly_created

  • Обновить то же самое в before_create и before_update callbacks как

    def before_create (record)
        record.newly_created = true
    end
    
    def before_update (record)
        record.newly_created = false
    end
    

Answer 4

Основываясь на идее leenasn, я создал несколько модулей, которые позволяют использовать обратные вызовы after_commit_on_update и after_commit_on_create: https://gist.github.com/2392664

Использование:

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

Answer 5

Взгляните на тестовый код: https://github.com/rails/rails/blob/master/activerecord/test/cases/transaction_callbacks_test.rb

Там вы можете найти:

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

и

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

Answer 6

Я использую следующий код, чтобы определить, является ли это новая запись или нет:

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

Это основано на идее, что новая запись имеет идентификатор по умолчанию, равный нулю, и затем изменяет ее при сохранении. Конечно, изменение идентификатора не является распространенным случаем, поэтому в большинстве случаев второе условие может быть опущено.

Answer 7

Мне любопытно узнать, почему вы не можете переместить свою after_commit логику в after_create и after_update. Есть ли какое-то важное изменение состояния, которое происходит между последними 2 вызовами и after_commit?

Если ваша обработка создания и обновления имеет некоторую пересекающуюся логику, вы могли бы просто заставить последние 2 метода вызвать третий метод, передав действие:

# 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

Если вы все еще предпочитаете использовать after_commit, вы можете использовать переменные потока. Это не приведет к утечке памяти до тех пор, пока разрешено собирать ненужные потоки.

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

Answer 8

Это похоже на ваш первый подход, но он использует только один метод (before_save или before_validate, чтобы действительно быть безопасным), и я не понимаю, почему это переопределит любое значение

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

Обновление

Это решение не работает, потому что, как утверждает @eleano, ItemObserver является Singleton, у него есть только один экземпляр. Таким образом, если 2 элемента сохраняются одновременно, @new_record может получить свое значение из item_1, а after_commit запускается item_2. Чтобы преодолеть эту проблему, должна быть item.id проверка / сопоставление для "постсинхронизации" 2 методов обратного вызова: hackish.

Answer 9

Вы можете изменить ловушку событий с after_commit на after_save, чтобы захватить все события создания и обновления. Затем вы можете использовать:

id_changed?

... помощник в наблюдателе. Это будет верно при создании и false при обновлении.