Rails 3: Come identificare l'azione after_commit negli osservatori? (crea/aggiorna/distruggi)

Question

Ho un osservatore e registro un callback after_commit. Come posso sapere se è stato attivato dopo la creazione o l'aggiornamento? Posso dire che un articolo è stato distrutto chiedendo item.destroyed? ma #new_record? non funziona poiché l'elemento è stato salvato.

stavo per risolverlo aggiungendo after_create/after_update e fare qualcosa di simile @action = :create all'interno e controllare il @action a after_commit, ma sembra che l'istanza osservatore è un Singleton e potrei ignorare un valore prima che arrivi al after_commit. Così l'ho risolto in modo più brutto, memorizzando l'azione in una mappa basata su item.id su after_create/update e controllandone il valore su after_commit. Davvero brutto.

C'è qualche altro modo?

Aggiornamento

Come @tardate detto, transaction_include_action? è una buona indicazione, anche se è un metodo privato, e in un osservatore dovrebbe essere letta con #send.

class ProductScoreObserver < ActiveRecord::Observer 
    observe :product 

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

Purtroppo, l'opzione :on non funziona in osservatori.

Assicurati di testare l'inferno dei tuoi osservatori (cerca test_after_commit gem se usi use_transactional_fixtures) così quando esegui l'aggiornamento alla nuova versione di Rails saprai se funziona ancora.

(testato su 3.2.9)

Update 2

al posto degli osservatori io uso ActiveSupport :: Preoccupazione e after_commit :blah, on: :create vi lavora.

Answer 1

Penso che transaction_include_action? sia quello che cerchi. Fornisce un'indicazione affidabile della transazione specifica in corso (verificata in 3.0.8).

Formalmente, determina se una transazione include un'azione per: create,: update o: destroy. Utilizzato nel filtrare i callback.

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 

Inoltre di interesse può essere transaction_record_state che può essere utilizzato per determinare se un record è stato creato o distrutto in una transazione. Lo stato dovrebbe essere uno di: new_record o: destroyed.

Aggiornamento per Rails 4

Per coloro che cercano di risolvere il problema in Rails 4, questo metodo è ormai deprecato, è necessario utilizzare transaction_include_any_action? che accetta un array di azioni.

Utilizzo Esempio:

transaction_include_any_action?([:create]) 

Answer 2

È possibile modificare il proprio hook di evento da after_commit a after_save, per acquisire tutti gli eventi di creazione e aggiornamento. È quindi possibile utilizzare:

id_changed? 

... helper nell'osservatore. Questo sarà vero su create e false su un aggiornamento.

Answer 3

Date un'occhiata al codice di prova: https://github.com/rails/rails/blob/master/activerecord/test/cases/transaction_callbacks_test.rb

Vi si possono trovare:

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

e

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

Answer 4

Questo è simile al tuo primo approccio ma utilizza un solo metodo (before_save o before_validate per essere davvero al sicuro) e non vedo perché questo dovrebbe prevalere su qualsiasi valore

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 

Aggiornamento

Questa soluzione non funziona perché come affermato da @eleano, ItemObserver è un Singleton, che ha una sola istanza. Quindi se 2 Item vengono salvati allo stesso tempo @new_record potrebbe prendere il suo valore da item_1 mentre after_commit viene attivato da item_2.Per superare questo problema ci dovrebbe essere un controllo/mappatura item.id per "post-synchornize" i 2 metodi di callback: hackish.

Answer 5

è possibile risolvere utilizzando due tecniche.

• L'approccio proposto dalla @nathanvda cioè controllando il created_at e updated_at. Se sono uguali, il record è stato appena creato, altrimenti è un aggiornamento.

• Utilizzando gli attributi virtuali nel modello. I passaggi sono:

  • Aggiungi un campo nel modello con il codice attr_accessor newly_created

  • Aggiornare lo stesso nel before_create e before_update callbacks come

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

Answer 6

Sulla base di un'idea leenasn, Ho creato alcuni moduli che consentono di utilizzare i callback after_commit_on_update e after_commit_on_create: 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 

Answer 7

ho imparato oggi che si può fare qualcosa di simile:

after_commit :do_something, :on => :create 

after_commit :do_something, :on => :update 

Dove fai_qualcosa è il metodo di callback che si desidera chiamare su determinate azioni.

Se si desidera chiamare lo stesso callback per aggiornamento e creare, ma non distruggere, è anche possibile utilizzare: after_commit :do_something, :if => :persisted?

in realtà non è documentato bene e ho avuto un momento difficile Googling esso. Fortunatamente, conosco alcune persone brillanti. Spero che sia d'aiuto!

Answer 8

Sono curioso di sapere il motivo per cui non si poteva spostare il after_commit logica in after_create e after_update. C'è qualche importante cambiamento di stato che si verifica tra le ultime 2 chiamate e after_commit?

Se la creazione e la gestione di aggiornamento ha una certa logica di sovrapposizione, si può solo avere gli ultimi 2 metodi chiamano un terzo metodo, passando all'azione:

# 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 

Se ancora piuttosto usa after_commit, è possibile utilizzare variabili del thread. Questo non perderà memoria finché i thread morti possono essere raccolti dalla garbage collection.

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 9

Io uso il seguente codice per determinare se si tratta di un nuovo record o no:

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

Si basa su un'idea che un nuovo record ha ID predefinito uguale a zero e poi cambia su Salva . Ovviamente la modifica dell'ID non è un caso comune, quindi nella maggior parte dei casi la seconda condizione può essere omessa.