Capire Ruby on Rails ActiveRecord Validations

Data è una grande cosa, ma i dati sbagliati possono essere molto molto cattivi. Fortunatamente, se sei un programmatore Ruby on Rails hai una bella API di helper di convalida ActiveRecord a tua disposizione.

Questa guida è un’esplorazione delle convalide ActiveRecord comuni e non così comuni in una determinata applicazione Ruby on Rails. Usalo per aiutare a mantenere felici i tuoi database!

Perché usare le convalide?

Per garantire che solo i dati validi vengano salvati nel database. Oltre alla convalida lato client, le convalide a livello di modello forniscono un ulteriore livello di sicurezza per tutti i campi del modulo all’interno di un’applicazione Ruby on Rails.

È possibile fornire convalide in una varietà di livelli, ma tutti hanno i loro punti di forza e di debolezza.

• Vincoli del database: vincoli univoci a livello di database non consentono campi o colonne duplicati, se necessario. Questo può andare molto più in profondità della semplice unicità. cioè valori predefiniti, vincoli non nili, intervalli, ecc…
• Convalida lato client-Questi sono utili visivamente e forniscono una migliore esperienza utente, ma sono spesso più inaffidabili. Quasi sempre fornirei un piano di backup usando questo approccio come si dovrebbe.
• Model Level (Rails) – Di cosa stiamo parlando ora!
• Controller Level (Rails) – Allettante da usare ma più difficile da testare e mantenere. È una convenzione / best-practice per mantenere i controller il più leggeri possibile.

Quando si verifica effettivamente la convalida?

Direttamente dalla documentazione di ruby on rails:

Esistono due tipi di oggetti Record attivi: quelli che corrispondono a una riga all’interno del database e quelli che non lo fanno. Quando si crea un nuovo oggetto, ad esempio utilizzando il metodo new, tale oggetto non appartiene ancora al database. Una volta chiamato save su quell’oggetto verrà salvato nella tabella del database appropriata. Active Record utilizza il metodo di istanza new_record? per determinare se un oggetto è già nel database o meno.

La creazione di una nuova classe di record attivi ci consente di utilizzare un metodo new_record? per capire tutto questo.

class Article < ApplicationRecordend

In tal modo possiamo colpirerails console per individuare il processo.

$ rails console>> article = Article.new(title: "My Article")=> #<Article id:nil title: "My Article", created_at: nil, updated_at: nil>>> article.new_record?=> true>> article.save=> true>> article.new_record?=> false

Chiamare effettivamente saveè ciò che lo impegna nel database e dietro le quinte crea le istruzioni necessarie SQL per farlo. Di conseguenza, le convalide vengono in genere eseguite prima di inviare interamente i dati al database.

I seguenti metodi di envoke convalide su di uso:

• create
• create!
• save
• save!
• update
• update!

Il bang versioni (ad esempio save!) solleva un’eccezione se il record non è valido. Le versioni non-bang non lo fanno: saveeupdaterestituiscefalse, ecreate restituisce solo l’oggetto.

I metodi che saltano le convalide

Utilizzando uno dei seguenti metodi salteranno completamente le convalide. Usare con cautela su dati preziosi!

• decrement!
• decrement_counter
• increment!
• increment_counter
• toggle!
• touch
• update_all
• update_attribute
• update_column
• update_columns
• update_counters

Validation helpers

What I love about Ruby on Rails is the bundled goodness you get for doing pretty hard things. Gli helper di convalida sono una di quelle cose che mi fanno sentire caldo e accogliente quando distribuisco una nuova app in natura. Ciò fornisce molto supporto per una vasta gamma di dati che potresti raccogliere dal lato client.

Ogni helper accetta un’opzione:on e:message. Queste opzioni definiscono quando deve essere eseguita la convalida e quale messaggio deve essere aggiunto a una raccolta errors se fallisce (puoi usarli per aiutare a iniettare cosa c’è di sbagliato nelle tue visualizzazioni in modo che l’utente sappia cosa cambiare/modificare).

Ci sono un sacco di helper di convalida, di seguito sono alcuni dei miei più utilizzati. Si prega di consultare la guida sulle convalide dei record attivi per ulteriori casi d’uso.

Conferma

Utile per convalidare quando due campi di testo devono avere la stessa voce. Pensate a una conferma e-mail per esempio.

class User < ApplicationRecord validates :email, confirmation: trueend

Ora nella tua vista puoi avere due campi:

<%= text_field :user, :email %><%= text_field :user, :email_confirmation %>

Un trucco qui è che questa convalida viene eseguita solo se l’opzionepresence è impostata su true anche nel modello.

Quindi il modelloUserottiene un aggiornamento:

class User < ApplicationRecord validates :email, confirmation: true validates :email_confirmation, presence: true end

Esclusione

Se hai bisogno di prenotare parole o assicurarti che una determinata voce sia unica usa exclusion.

class Profile < ApplicationRecord validates :username, exclusion: { in: %w(username1 username2 username3), message: "%{value} has already been taken." }end

Si noti come ho usato :message anche qui. Questo è fornito su tutti gli helper di convalida.

Puoi anche usare inclusion nel modo opposto. Vedere i documenti per maggiori informazioni!

Formato

Le stringhe di formattazione sono a volte ideali per la tua app. Puoi usare le espressioni regolari all’interno delle convalide per modificare qualsiasi cosa tu stia cercando.

class Plan < ApplicationRecord validates :plan_type, format: { with: /\A+\z/, message: "Plans can only inlude letters"}end

Length

Io uso questo tutto il tempo per mettere un vincolo sulla lunghezza dei caratteri di un dato campo.

class User < ApplicationRecord validates :name, length: { minimum: 5 } # sets a minimum validates :bio, length: { maximum: 500 } # sets a maximum validates :handle, length: { in: 5..16 } # provide a rangeend

Sentiti libero di personalizzare i messaggi con :message anche qui. I seguenti sono tutti disponibili per collegare in per personalizzare il messaggio.

• wrong_length
• too_long
• too_short

Esempio

class User < ApplicationRecord validates :bio, length: { maximum: 800, too_long: "%{count} characters is the maximum." }end

Presenza

Questo è probabilmente il più ampiamente usato helper nel mio sacchetto. Presenza controlla che i campi non siano vuoti.

class User < ApplicationRecord validates :name, :email, presence: trueend

È possibile anche verificare esiste un’associazione su modelli

class Article < ApplicationRecord belongs_to :user validates :user, presence: true # looks for a user_id field on the articleend

Su avversaria modello, si può fare lo stesso con uno di cattura denominata inverse_of

class User < ApplicationRecord has_many :articles, inverse_of: :userend

Unicità

Forse si vuole nomi utente sulla vostra app? L’unicità aiuta con questo.

class User < ApplicationRecord validates :username, uniqueness: true, { message: "Username already taken" }end

Questo cerca effettivamente la tabella User per i record esistenti per determinare uniqueness

È possibile andare oltre e limitare uniqueness fino a un massimo di scope.

class User < ApplicationRecord validates :plan, uniqueness: { scope: :year, message: "can only update one per year"}end

Convalide condizionali

A volte è necessario convalidare solo in determinate condizioni. È possibile eseguire condizionali utilizzando un approccio come il seguente.

class Purchase < ApplicationRecord validates :card_number, presence: true, if: :paid_with_card? def paid_with_card? payment_type == "card" endend

È necessario raggruppare più condizioni? Puoi farlo

class User < ApplicationRecord with_options if: :is_admin? do |admin| admin.validates :location, length: { minimum: 10 } admin.validates :job_title, presence: true endend

Metodi personalizzati

A volte gli helper non sono sufficienti e potresti aver bisogno di qualcosa di più personalizzato. È possibile creare i propri metodi che fanno alcune convalide si tira da soli.

class Invoice < ApplicationRecord validate :active_subscriber, on: :create def active_customer errors.add(:customer_id, "is not active") unless subscriber.active? endend

Nota qui sto convalidando questo metodo usando l’opzione :on che consente di determinare dove inizializzare la convalida. In questo caso ho scelto :create.

Puoi anche collegarti alla raccolta errors poiché devo modificare le uscite sul lato client se necessario. Non abbiamo :message sui metodi personalizzati in questo caso. Per saperne di più sugli errori.

Parole finali

Si spera che le convalide abbiano aperto alcune idee per rendere la tua app più vincolata (in senso buono). L’utilizzo di Ruby on Rails e di tutte le sue sfaccettature consente di inserire dati sicuri in qualsiasi database di tua scelta. Dai token CSRF alle convalide a livello di database, ci sono infiniti modi per migliorare la tua app in grado di mantenere la calma sui dati in arrivo.

Spina spudorata!

Se ti è piaciuto questo post, ho altri video su YouTube e qui sul mio blog. Vuoi più contenuti come questo nella tua casella di posta? Iscriviti alla mia newsletter e farlo automaticamente.

Controlla il mio corso

Want Vuoi imparare Ruby on Rails da zero? Dai un’occhiata al mio prossimo corso chiamato Hello Rails.