t.string :name, :null => false - is being ignored! (Devise)

People,

I have included the devise gem in an app and it is going OK but I needed a name field as well as the email so I added it to the migration file:

class DeviseCreateUsers < ActiveRecord::Migration
   def change
     create_table(:users) do |t|
       ## Database authenticatable
       t.string :name, :null => false, :default => ""
       t.string :email, :null => false, :default => ""
       .

and recreated the DB, the schema.rb:

create_table "users", force: true do |t|
t.string "name", default: "", null: false
t.string "email", default: "", null: false
.

confirms that the change looks sensible, however when I add a new user, I can do it without the user name! - how is that possible?

Any help appreciated!

Thanks,

Phil.

In Ruby a blank string is a null note a null bit so you need if you
set :default => "" it will allow blank strings, which means your model
needs to validate with :allow_blank => false or you need to set the
ALLOW NULL 0 on the field by doing `:null => false` without the
":default => true".

The preferable solution from both a security and a proper application
standpoint is to do tell both the model and the db that it doesn't
want null or blank strings because a db error should protect against
manual entries and the model would be quicker when testing for blank
strings, you can do that with "validates :field, :allow_blank =>
false, allow_nil => false"

In Ruby a blank string is a null note a null bit so you need if you

That should say "In Ruby a blank is not a null bit."

Apparently my laptops touchpad was on so let me reword it:

In Ruby a blank string is not a null bit so if you set :default => ""
it will allow blank strings, which is what you consider a null string
even though there is no such thing. Which means if you want :default
=> "" you need to have your model validate with :allow_blank => false,
or you need to ALLOW_NULL 0 and remove the :default => "".

The preferable solution from both a security and proper application
standpoint is to tell both the model and the db that it doesn't want
null or blank strings because it's faster to have the model do blank?
than it is to hit the db and have it return and error and complete a
cycle (short-circuiting is a good thing.) The db protection is simply
to protect yourself against manual entries and edge cases in the
application.

Jordon,

Apparently my laptops touchpad was on so let me reword it:

In Ruby a blank string is not a null bit so if you set :default => ""
it will allow blank strings, which is what you consider a null string
even though there is no such thing. Which means if you want :default
=> "" you need to have your model validate with :allow_blank => false,
or you need to ALLOW_NULL 0 and remove the :default => "".

The preferable solution from both a security and proper application
standpoint is to tell both the model and the db that it doesn't want
null or blank strings because it's faster to have the model do blank?
than it is to hit the db and have it return and error and complete a
cycle (short-circuiting is a good thing.) The db protection is simply
to protect yourself against manual entries and edge cases in the
application.

Right - I should have realised that what I was looking at was the DB stuff - I have found:

.gem/ruby/bundler/gems/devise-4e2cdc2d5b81/lib/devise/models/validatable.rb

and it seems to have some stuff in it that is relevant - I will check that out.

Thanks,

Phil.