Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md to include CreateUsers migration example #191

Merged
merged 2 commits into from
Dec 18, 2023
Merged

Update README.md to include CreateUsers migration example #191

merged 2 commits into from
Dec 18, 2023

Conversation

mzrnsh
Copy link
Contributor

@mzrnsh mzrnsh commented Dec 8, 2023

In the README, we already give a code sample that creates User model and CreateUsers migration:

$ bin/rails generate model User email

And then we display the code for User model, showing how to mark the passwordless email field:

class User < ApplicationRecord
  validates :email,
            presence: true,
            uniqueness: { case_sensitive: false },
            format: { with: URI::MailTo::EMAIL_REGEXP }

  passwordless_with :email # <-- here!
end

Since this snippet already shows the example of how to validate an email field, I believe it's useful to also feature a snippet that adds similar db-level constraint. The idea is to ensure data integrity in case records are modified outside Rails (or within Rails when validations are skipped).

Here's how I do it:

class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :email, null: false

      t.index 'LOWER(email)', unique: true, name: 'index_users_on_lowercase_email'

      t.timestamps
    end
  end
end

It is not exactly the same as the model validation - this doesn't validate email format. But personally, I don't care because this is only to ensure email uniqueness. If an invalid email is saved forcibly, the worst that's going to happen is that that one user won't be able to log in.

@djfpaagman
Copy link
Contributor

Rails 7.1 added normalizing the ActiveRecord, that could also be a useful approach for this problem.

@mzrnsh
Copy link
Contributor Author

mzrnsh commented Dec 13, 2023

That's a cool new feature. But would it not affect the only model, meaning uniqueness should still be enforced at database level?

@mikker
Copy link
Owner

mikker commented Dec 13, 2023

I feel like we should maybe instead move all the user setup to a separate file, maybe a wiki page. I don't want to add too much to the README as it quickly becomes tl;dr.

On the other hand this is good information and definitely something lesser experienced devs will find helpful and appreciate.

Something like a page called "Creating a proper User class". What do you think?

Refer the wiki instead of including everything in the README
@mzrnsh
Copy link
Contributor Author

mzrnsh commented Dec 13, 2023

Good idea! Added the wiki page, and updated the README to point to it.

https://github.com/mikker/passwordless/wiki/Creating-the-user-model

@mikker
Copy link
Owner

mikker commented Dec 18, 2023

I like this. Thanks!

@mikker mikker merged commit 783c0c4 into mikker:master Dec 18, 2023
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants