Rails Observer, как определить, что вызвало after_destroy

Question

У меня есть наблюдатель, настроенный следующим образом:

class FeedObserver < ActiveRecord::Observer
  observe :permission
  def after_destroy(record)

    Rails.logger.info 'XXXXXXXXXXXXXXXXXXXXXXXXX    Feed Observer - after_destroy      XXXXXXXXXXXXXXXXXXXXXXXXXXX'
    Rails.logger.info record.inspect
    Rails.logger.info record.class.name
    Rails.logger.info record.class
    Rails.logger.info 'XXXXXXXXXXXXXXXXXXXXXXXXX    Feed Observer - after_destroy      XXXXXXXXXXXXXXXXXXXXXXXXXXX'

  end

end

В журналах это выглядит примерно так:

XXXXXXXXXXXXXXXXXXXXXXXXX    Feed Observer - after_destroy      XXXXXXXXXXXXXXXXXXXXXXXXXXX
#<Permission id: 52, project_id: 12, role_id: 2, user_id: 1>
Permission
Permission
XXXXXXXXXXXXXXXXXXXXXXXXX    Feed Observer - after_destroy      XXXXXXXXXXXXXXXXXXXXXXXXXXX

Проблема в том, что в моем контроллере разрешений есть два метода, которые могут удалить объект разрешения, destory и leftproject.

В наблюдателе, как я могу определить, какой метод был вызван, что привело к вызову обозревателя Ленты?

Спасибо

Answer 1

Попробуйте Kernel # caller, который вернет обратную трассировку в этот момент в стеке выполнения. Попробуйте это так:

def after_destroy(record)
  Rails.logger.info caller.join("\n")
  ...

Вы получите немного вывода, но если вы пропустите материал инфраструктуры rails, вы должны найти код вашего контроллера.

Answer 2

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

class Work < ActiveRecord::Base
  def destroy_work(from)
    self.destroy
    Rails.logger.info "The work with the id of #{id} got destroyed by #{from}"
  end
end

Не полагаясь на сложное метапрограммирование (например, на проверку стека вызовов), вы делаете свою программу намного более устойчивой, а также намного более легкой для понимания. То же самое относится к обратным вызовам и тем более к классам внешних наблюдателей. В исходной модели обычно присутствуют лишь небольшие следы существования обратных вызовов (если они вообще есть). Это делает анализ поведения очень сложным и подверженным ошибкам, поскольку вы можете легко пропустить потенциально важные части вашей бизнес-логики. Внедряя прямые функции, вы облегчаете понимание своей логики, следуя простой прямой линии.

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

Answer 3

Ну, вы не можете знать, но я не должен это быть так трудно выяснить.

it after destroy, если вы следуете соглашениям, оно должно быть в feeds_controller.rb т.е. FeedsController#destroy , или в случае :dependent => :destroy ассоциаций, оно должно быть в контроллере ассоциаций в действии destroy.

есть еще один простой способ: поднять фиктивную ошибку с помощью метода ruby ​​ raise и пройтись по трассировке стека