Uniqueness validation in Ruby on Rails - Step-by-Step Execution

Concept Flow - Uniqueness validation

Start: New record input

↓

Check if value exists in DB?

↓

Add error

↓

Reject save

↓

End

Rails checks if the value already exists in the database before saving. If it does, it adds an error and rejects saving. Otherwise, it saves the record.

Execution Sample

Ruby on Rails

class User < ApplicationRecord
  validates :email, uniqueness: true
end

This code ensures that each User's email is unique before saving to the database.

Execution Table

Step	Input Email	DB Check Result	Validation Result	Action
1	"[e-mail]"	Not found	Valid	Record saved
2	"[e-mail]"	Found	Invalid	Save rejected with error
3	"[e-mail]"	Not found	Valid	Record saved

💡 Execution stops when record is saved or rejected based on uniqueness check.

Variable Tracker

Variable	Start	After 1	After 2	After 3
email	nil	"[e-mail]"	"[e-mail]"	"[e-mail]"
validation_result	nil	Valid	Invalid	Valid
record_saved	false	true	false	true

Key Moments - 2 Insights

Why does the second record with the same email fail to save?

Because the uniqueness validation checks the database and finds the email already exists (see execution_table step 2), so it marks the record invalid and rejects saving.

Does uniqueness validation check only the current input or the whole database?

It checks the whole database for existing records with the same value before saving, as shown in the DB Check Result column in the execution_table.

Visual Quiz - 3 Questions

Look at the execution table, what is the validation result at step 2?

A Invalid

B Not checked

C Valid

D Error

💡 Hint

Check the 'Validation Result' column at step 2 in the execution_table.

At which step does the record get saved with a new email?

A Step 1

B Step 2

C Step 3

D No record is saved

💡 Hint

Look at the 'Action' column in the execution_table for when 'Record saved' happens with a new email.

If the email at step 3 was changed to "[e-mail]", what would happen?

A Record saved

B Save rejected with error

C Validation skipped

D Database error

💡 Hint

Refer to step 2 where the same email caused save rejection due to uniqueness validation.

Concept Snapshot

Uniqueness validation in Rails:
- Use validates :field, uniqueness: true
- Checks DB for existing value before save
- If found, adds error and rejects save
- Ensures no duplicate values in that field
- Works automatically on save/update

Full Transcript

Uniqueness validation in Rails ensures that a field's value is unique in the database before saving a record. When you try to save a record, Rails checks if the value already exists. If it does, it adds an error and prevents saving. If not, it saves the record. For example, validating uniqueness of email means no two users can have the same email. The execution table shows three steps: first saving a new email succeeds, second saving the same email fails, and third saving a different email succeeds. Variables like email, validation result, and record saved change accordingly. This helps prevent duplicate data in your app.

Practice

1. What does validates :email, uniqueness: true do in a Rails model?

easy

A. Deletes duplicate email records from the database

B. Prevents saving records with duplicate email values

C. Allows multiple records with the same email

D. Automatically encrypts the email field

Solution

1. Step 1: Understand uniqueness validation purpose

   Uniqueness validation ensures no two records have the same value for the specified field.

2. Step 2: Apply to the email field

   Using validates :email, uniqueness: true means Rails will check that the email is unique before saving.

3. Final Answer:

   Prevents saving records with duplicate email values -> Option B

4. Quick Check:

   Uniqueness validation = prevents duplicates [OK]

Hint: Uniqueness validation stops duplicate field values [OK]

Common Mistakes:

• Thinking it encrypts data
• Assuming it deletes duplicates automatically
• Believing it allows duplicates

2. Which is the correct syntax to add uniqueness validation for a username in a Rails model?

easy

A. validates :username, unique: true

B. validate :username, uniqueness: true

C. validates :username, uniqueness: true

D. validates_uniqueness_of :username, true

Solution

1. Step 1: Recall Rails validation syntax

   Rails uses validates :field, uniqueness: true for uniqueness validation.

2. Step 2: Check each option

   validates :username, uniqueness: true matches the correct syntax exactly; others have syntax errors or deprecated style.

3. Final Answer:

   validates :username, uniqueness: true -> Option C

4. Quick Check:

   Correct uniqueness syntax = validates :field, uniqueness: true [OK]

Hint: Use 'validates :field, uniqueness: true' syntax [OK]

Common Mistakes:

• Using 'unique' instead of 'uniqueness'
• Using 'validate' instead of 'validates'
• Using deprecated 'validates_uniqueness_of' syntax incorrectly

3. Given this model code:

class User < ApplicationRecord
  validates :email, uniqueness: true
end

What happens if you try to save two users with the same email?

medium

A. The second user fails to save due to validation error

B. Both users save successfully

C. An exception is raised immediately

D. The database automatically rejects the second user

Solution

1. Step 1: Understand Rails validation behavior

   Uniqueness validation runs before saving and prevents duplicates by adding errors.

2. Step 2: Effect on saving duplicate email

   The first user saves fine; the second user triggers validation failure and does not save.

3. Final Answer:

   The second user fails to save due to validation error -> Option A

4. Quick Check:

   Uniqueness validation blocks duplicates on save [OK]

Hint: Second duplicate save triggers validation error [OK]

Common Mistakes:

• Thinking both save successfully
• Expecting a database exception instead of validation error
• Assuming database rejects without validation

4. Identify the problem in this model code:

class Product < ApplicationRecord
  validates :code, uniqueness: true
  validates :code, presence: true
end

Why might duplicates still be saved?

medium

A. Uniqueness validation is case sensitive by default

B. Presence validation conflicts with uniqueness validation

C. The validations are in the wrong order

D. No unique index exists in the database for code

Solution

1. Step 1: Understand validation vs database constraints

   Rails validations check before saving but do not guarantee uniqueness at the database level.

2. Step 2: Check for unique index necessity

   Without a unique database index on code, race conditions can allow duplicates.

3. Final Answer:

   No unique index exists in the database for code -> Option D

4. Quick Check:

   Validation alone can't prevent duplicates without DB index [OK]

Hint: Add unique DB index to fully prevent duplicates [OK]

Common Mistakes:

• Assuming validations alone guarantee uniqueness
• Confusing presence and uniqueness validations
• Thinking validation order matters here

5. You want to ensure usernames are unique but case insensitive (e.g., 'User1' and 'user1' count as duplicates). How do you write the validation?

hard

A. validates :username, uniqueness: { case_sensitive: false }

B. validates :username, uniqueness: true, case_sensitive: false

C. validates :username, unique: { case_sensitive: false }

D. validates_uniqueness_of :username, case_sensitive: true

Solution

1. Step 1: Recall uniqueness validation options

   To make uniqueness case insensitive, use uniqueness: { case_sensitive: false }.

2. Step 2: Check each option's correctness

   validates :username, uniqueness: { case_sensitive: false } uses correct syntax and option key; others have syntax errors or wrong case sensitivity.

3. Final Answer:

   validates :username, uniqueness: { case_sensitive: false } -> Option A

4. Quick Check:

   Case insensitive uniqueness = uniqueness: { case_sensitive: false } [OK]

Hint: Use uniqueness with case_sensitive: false for case insensitivity [OK]

Common Mistakes:

• Placing case_sensitive outside uniqueness hash
• Using 'unique' instead of 'uniqueness'
• Setting case_sensitive to true by mistake