Înregistrează o înregistrare activă de redirecționare

Înregistrare activă

Acest tutorial vă va învăța să interferați cu ciclul de viață al obiectelor Active Record.

După ce ați citit acest ghid, veți învăța:







  • Despre ciclul de viață al obiectelor Active Record
  • Cum se creează metode de apeluri care răspund la evenimentele din ciclul de viață al unui obiect
  • Cum să creați clase speciale care încorporează comportamentul obișnuit pentru apelurile telefonice

1. Ciclul de viață al unui obiect

Ca urmare a operațiunilor normale ale aplicației pe șine, obiectele pot fi create, actualizate și distruse. Înregistrare activă oferă posibilitatea de a interveni în acest ciclu de viață al obiectului, astfel încât să puteți controla aplicația și datele acesteia.

Validările vă permit să vă asigurați că numai date valide sunt stocate în baza dvs. de date. Kolbacks vă permit să schimbați logica înainte sau după modificarea stării unui obiect.

2. Privire de ansamblu asupra apelurilor telefonice

Cooldbacks sunt metode numite în anumite puncte din ciclul de viață al unui obiect. Cu callback este posibil să se scrie cod care va rula atunci când obiectul este creat active record, menținut, actualizat, șters, sau este validat este încărcat din baza de date.

2.1. Verificarea apelurilor

Pentru a utiliza apelurile de apel disponibile, trebuie să fie înregistrate. Aveți posibilitatea să implementați callback-urile ca metode normale și apoi să utilizați metodele macro ale clasei pentru a le înregistra ca callbacks.

Metodele macro ale clasei pot primi, de asemenea, un bloc. Acestea pot fi folosite dacă codul din interiorul blocului este atât de scurt încât se potrivește într-o singură linie.

Comenzile de returnare pot fi, de asemenea, înregistrate pentru executarea la anumite evenimente de ciclu de viață:

Se consideră o practică bună declararea metodelor de apeluri ca fiind private. Dacă sunt lăsate publice, pot fi chemați din afara modelului și încalcă principiile încapsulării obiectului.

3. Callback-urile disponibile

Iată o listă a tuturor vrăjitorilor Active Record disponibili, listați în ordinea în care sunt numiți în timpul operațiilor corespunzătoare:

3.1. Creați un obiect

  • before_validation
  • after_validation
  • before_save
  • around_save
  • before_create
  • around_create
  • after_create
  • after_save
  • after_commit / after_rollback

3.2. Actualizați un obiect

  • before_validation
  • after_validation
  • before_save
  • around_save
  • before_update
  • around_update
  • after_update
  • after_save
  • after_commit / after_rollback

3.3. Distrugerea unui obiect

  • before_destroy
  • around_destroy
  • after_destroy
  • after_commit / after_rollback

after_save se execută atât atunci când se creează și se actualizează, dar întotdeauna după cele mai specifice apeluri after_create și after_update. indiferent de ordinea în care sunt pornite apelurile macro.

Prior_destroy trebuie plasat înaintea dependențelor. distrugeți (sau utilizați opțiunea prepend: true) pentru a vă asigura că acestea sunt executate înainte ca fișierele să fie șterse utilizând dependente. distruge.

3.4. after_initialize și after_find

Apelul de recuperare after_initialize este apelat ori de câte ori un obiect Active Record este instanțiat sau direct atunci când se utilizează un nou. sau când înregistrarea este încărcată din baza de date. Poate fi util să se evite necesitatea de a suprascrie direct metoda Active Record initialize.

Simbolul after_find va fi apelat ori de câte ori Active Record încarcă o intrare din baza de date. after_find este apelat înainte de după_initializare. dacă ambele sunt definite.

Semnele de răspuns after_initialize și after_find nu au o pereche anterior_ *. dar pot fi înregistrate ca alte wiki-uri Active Record.

3.5. after_touch

Aftertouch-ul after_touch va fi sunat atunci când se apelează atingerea pe obiectul Active Record.

Poate fi folosit împreună cu aparatul:

4. Redarea apelurilor

Următoarele metode execută apeluri inverse:

În plus, apelul after_find este invocat de următoarele metode de căutare:

Tocoul after_initialize este declanșat ori de câte ori este inițializat un obiect de clasă nou.







Metodele find_by_ * și find_by_ *! Acestea sunt metode de căutare dinamice generate automat pentru fiecare atribut. Aflați mai multe în secțiunea Căutare dinamică.

5. Sari peste apelurile de apel

Similar cu validările, este posibil să ignorați apelurile de apel folosind următoarele metode.

  • decrementare
  • decrement_counter
  • șterge
  • delete_all
  • creștere
  • increment_counter
  • comutare
  • atinge
  • update_column
  • update_columns
  • update_all
  • update_counters

Cu toate acestea, aceste metode ar trebui folosite cu precauție, deoarece regulile de afaceri importante și logica aplicațiilor pot fi conținute în apelurile de apel. Trecerea lor fără înțelegerea consecințelor posibile poate duce la date nevalide.

6. Întreruperea performanței

Odată ce ați înregistrat noii vrăjitori în modelele dvs., aceștia vor fi în așteptare pentru execuție. Această coadă include toate validările modelului dvs., operațiile de retur apelate și operațiile de bază de date pentru execuție.

Întregul lanț de callback-uri este împachetat într-o operație. Dacă orice apel invocă o excepție, lanțul executat este terminat și ROLLBACK este pornit. Pentru a opri lanțul, utilizați:

Un apel la o excepție arbitrară poate fi întrerupt de un cod care presupune că salvarea și altele asemănătoare nu vor fi dezactivate în acest fel. Excepție ActiveRecord :: Rollback este o informare puțin mai precisă a înregistrării active pe care o are declanșarea. El preia din interior, dar nu răstoarnă excepția.

Orice excepție, cu excepția ActiveRecord :: Rollback sau ActiveRecord :: RecordInvalid. Șinele vor fi redirecționate după întreruperea lanțului de apelări. Apelarea unei alte excepții decât ActiveRecord :: Rollback sau ActiveRecord :: RecordInvalid. poate rupe un cod care nu se asteapta ca metode precum save si update_attributes (care de obicei incearca sa returneze true sau false) vor arunca o exceptie.

7. Coimbus pentru relații

Collabii lucrează cu relațiile dintre modele și pot fi chiar definiți de ei. Imaginați-vă un exemplu în care un utilizator are mai multe articole. Articolele de utilizator trebuie să fie distruse dacă utilizatorul este șters. Să adăugăm după_destroy modelului Utilizator prin relația sa cu modelul Articol.

8. Redirecționări condiționate

Ca și în validare, este posibil să se facă un apel la metoda de apel invers condiționat, în funcție de predicatul dat. Aceasta se face folosind opțiunile: if and: unless. care poate lua un caracter, Proc sau un matrice. Opțiunea: dacă ar trebui utilizată pentru a determina în ce condiții trebuie apelat callback-ul. Dacă doriți să definiți condițiile în care apelul nu trebuie apelat, utilizați opțiunea: excepție.

8.1. Utilizare: dacă și: cu excepția unui personaj

Opțiuni: dacă și: cu excepția cazului în care pot fi asociate cu un simbol corespunzător denumirii metodei predicate, care va fi apelat imediat înainte de a apela callback-ul. Dacă utilizați opțiunea: if. Redirecționarea apelului nu va fi executată dacă metoda predicatelor returnează false; atunci când utilizați opțiunea: excepție. Callback-ul nu va fi executat dacă metoda predicate revine la adevărat. Aceasta este cea mai frecventă opțiune. Atunci când se utilizează un astfel de formular de înregistrare, este posibilă și înregistrarea mai multor predicate diferite care vor fi chemați pentru a verifica dacă trebuie declanșat un apel invers.

8.2. Utilizare: dacă și: cu excepția cazului în Proc

În cele din urmă, puteți asocia: dacă și: cu excepția cazului în care obiectul Proc. Această opțiune este cea mai potrivită pentru scrierea metodelor scurte, de obicei, cu o singură linie.

8.3. Condiții compuse pentru apelurile de apel

9. Clase de apeluri

Uneori, metode scrise de apeluri sunt destul de utile pentru reutilizare în alte modele. Înregistrare activă face posibilă crearea de clase care includ metode de apel invers, astfel încât să devină foarte ușor să le reutilizați.

Iată un exemplu în care creați o clasă cu apelul after_destroy pentru modelul PictureFile:

Dacă metoda de apel invers este declarată astfel, nu este nevoie să instanțiați obiectul PictureFileCallbacks.

În cadrul clasei de apel invers, puteți să creați cât mai multe apeluri de apel pe care le doriți.

10. Redirecționări de tranzacții

Există două apeluri suplimentare care sunt incluse atunci când tranzacția bazei de date se termină: după_comandă și după returnare. Aceste apeluri de apel sunt foarte asemănătoare cu după_save. cu excepția faptului că acestea nu sunt inițiate până când modificările din baza de date sunt verificate sau adresate. Acestea sunt cele mai utile atunci când modelele Active Record trebuie să interacționeze cu sisteme externe care nu fac parte din tranzacția bazei de date.

Luați în considerare, de exemplu, exemplul anterior în care modelul PictureFile trebuie să șterge fișierul după distrugerea înregistrării. Dacă ceva aruncă o excepție după ce a fost chemat post_destroy. iar tranzacția este derulată înapoi, fișierul va fi șters și modelul va rămâne într-o stare inconsistentă. De exemplu, să presupunem că picture_file_2 din codul următor nu este valid și metoda de salvare! va provoca o eroare.

Utilizarea funcției after_commit. putem lua în considerare acest caz.

Opțiunea: on (Activat) specifică momentul în care va fi pornit apelul de apel. Dacă nu oferiți o opțiune: activată. Se va lansa apelul pentru fiecare acțiune.

Din moment ce este obișnuit să folosiți după_commit după crearea, actualizarea sau ștergerea, există aliasuri pentru aceste operații:

  • after_create_commit
  • after_update_commit
  • after_destroy_commit

After_commit și after_rollback sunt solicitate pentru toate modelele create, actualizate sau șterse din cadrul blocului de tranzacții. Cu toate acestea, în cazul în care orice excepție este invocată într-una dintre aceste callback, această excepție se va deschide, și orice metode rămase after_commit sau after_rollback nu sunt îndeplinite. De fapt, dacă codul apelului dvs. poate arunca o excepție, trebuie să apelați salvarea pe acesta și să îl procesați în apelul de apel pentru a permite ca alte apelări să fie difuzate.

Când se utilizează funcțiile after_create_commit și after_update_commit în același model, va funcționa doar apelul invers definit de ultimul, redefinind toate celelalte.

Pentru a înregistra apelurile pentru acțiuni de creare și actualizare, utilizați funcția after_commit.







Trimiteți-le prietenilor: