Quindi sto usando il rails3_acts_as_paranoid gem e ho qualche problema nel controllo dell'ambito con has_many: attraverso le associazioni.Rails act_as_paranoid e has_many: through
Per esempio
# User.rb
acts_as_paranoid
has_many :folders
has_many :files, :through => :folders
-
# Folder.rb
acts_as_paranoid
belongs_to :user
has_many :files, :dependent => :destroy
-
# File.rb
acts_as_paranoid
belongs_to :files
Ora lascia solo dire da qualche parte nel users_controller.rb voglio interrogare tutti i file appartenenti a un utente, se sono cancellati e/o appartengono a cartelle che sono state cancellate. Così, naturalmente, vorrei assumere per fare qualcosa di simile alla seguente
current_user.files.with_deleted
with_deleted metodo fa il suo lavoro a rimuovere il files.deleted_at IS NULL
... MA ... doesnt rimuovere il default_scope per le cartelle che viene utilizzato tipo di dietro la tenda. Quindi abbiamo ancora una condizione folders.deleted_at IS NULL, che mi impedisce di recuperare i file che appartengono a quelle cartelle dove deleted_at non è nullo.
Voglio continuare a utilizzare act_as_paranoid, in quanto è incredibilmente utile in tutti gli altri punti della mia app, e sto cercando di non fare qualcosa come il filtraggio manuale e l'apertura degli elementi dell'array .where_values. Ma non so molto sulla gestione degli ambiti complessi o sui metodi disponibili.
Sembra che il metodo #unscoped sia quello che stai cercando qui: http://apidock.com/rails/ActiveRecord/Scoping/Default/ClassMethods/unscoped – pjam
Ho provato il metodo senza ambito, ma questo elimina lo scopo di automagic unire il bridging ai file, in particolare 'INNER JOIN folders ON files.folder_id = folders.id WHERE folders.user_id = 1' a meno che forse non mi sia sfuggito una funzione di unscoped per mantenerlo? – Misterparker
Sto ancora verificando se trovo una soluzione, ma mi limito a notare che la riga '@user = User.find current_user.id' è inutile, mentre stai ricaricando l'attuale_user – pjam