3

I tried looking for an answer but they were all using User.new etc and not create.

When using User.create() in console with valid attributes I'm getting a User created with nil for ID and nil for the timestamps.

Here is my user Model.

 class User < ApplicationRecord
  attr_writer :name, :email
  before_save {self.email = email.downcase}

  validates :username, presence:true,
                       length: {maximum: 30},
                       uniqueness:true


  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i
  validates :email, presence:true,
                    length: {maximum:200},
                    format: {with: VALID_EMAIL_REGEX},
                    uniqueness: {case_sensitive: false}

  has_secure_password

  validates :password, presence: true,
                       length: {minimum:6}

end

In the rails console I'm using 

User.create(username:"oiuedhioj", email:"damhan@dagr.com",password:"test",password_confirmation:"test")

And getting back 

<User id: nil, username: "Damhan", email: nil, created_at: nil, updated_at: nil, password_digest: "$2a$10$oGtRgcHigaHh/UCVX4QdM.AOgyGur8Oud5MyKZheUcQ...">
Eyeslandic
  • 14,553
  • 13
  • 41
  • 54
Damhan Richardson
  • 419
  • 1
  • 5
  • 16

3 Answers3

5

Try doing the creation in the rails console.

Returning a record without an Id or timestamps is a sign of an invalid record.

user = User.create(...)
user.valid?
=> false
user.errors.any?
=> true
fbelanger
  • 3,522
  • 1
  • 17
  • 32
1

You've set only name and email as writable. Include id and other properties on that list. Or if your rails version is 4+, use strong parameters in your controller.

#user_controller.rb

...
private

def user_params
  params.require(:user).permit(:id, :name, :email ... )
end
...
marmeladze
  • 6,468
  • 3
  • 24
  • 45
  • Rails adds all columns as accessible by default. What your thinking of is attr_accessible from Rails 3. – fbelanger Apr 16 '17 at 21:57
1

In addition to the tips you already got, use create! and save! etc. instead of their complements to get an exception on error, and thus fail-fast and hence easier to debug code. Only use the variants without ! if you have a good reason. As you have to manually check for errors anyway, having proper exceptions is usually much more cleaner.

AnoE
  • 8,048
  • 1
  • 21
  • 36
  • Nah don't use `!` in production code. Unless you're prepared to catch the exceptions. AR was designed to fail because of validation, without raising exceptions. This way you can complete the request and simply respond with the form with error fields when these are present. – fbelanger Apr 17 '17 at 02:07
  • Yes, absolutely use `!` in production. Validations work just fine with it. Obviously you do catch the exception of you expect one to happen and know how to handle it! Manually checking for errors just is an open invitation for the hardest kinds of bugs. Google "fail fast" to see what I mean. @fbelanger – AnoE Apr 17 '17 at 08:52
  • No do not use bang in production on AR. Sure use raising exceptions elsewhere but your wrong to raise exceptions for each possible validation. Reason being this forces manual checking (catching). While sending a object with errors back to the form will highlight fields. http://stackoverflow.com/questions/1761076/when-do-i-use-save-create-and-update-attributes-in-rails – fbelanger Apr 17 '17 at 15:36
  • @fbelanger, it makes zero sense for us to discuss this back and forth like this. I gave my arguments which go way beyond validation and won't continue. Never mind. – AnoE Apr 17 '17 at 15:41
  • It makes no sense because all you did is puke your argument without really discussing anything assuming your righteousness. At least I argued using your proposal. I understand very well what fail fast I don't need to google, plus doesn't apply here. Fail fast from a DB layer sure, fail fast a AR record have you not read basic error handling with Rails? After you catch your exception you'll do what rails would of done or something far worst and unmaintainable. – fbelanger Apr 17 '17 at 15:49
  • I used to do raise an exception for UnpermittedParams because it can easier during development. I stopped since I rather the user accomplish something they're used to then not being able to do anything because of a new field in a form without strong params. Fail fast simply does not belong in the request cycle, anywhere else gladly. – fbelanger Apr 17 '17 at 15:54