Re: ActiveRecord uses confusing defaults

John Higgins
Sun, 10 Sep 2006 01:24:01 -0000

Jeroen,

You aren''t going nuts - it''s just AR trying to make
it''s best interpretation
of what it gets and this may very well be an edge case that could be up for
discussion.

First, the migrations are simply used to create your table - they bear not
on the actual model classes used later on. AR makes a call to "show
fields"
on the database and creates the column classes from there. Where you are
running into an issue is that show fields returns a blank string for both of
your example fields and AR makes it''s best guess from there based on
the
field type. For the string field - AR would have no choice but to do as it
does because a blank string is a perfectly valid option for a string field
default and therefore it needs to handle that case in that way. The integer
column is a different story and you raise what I think would be an
interesting idea that since a blank string is not a zero - then AR should
not be making that leap in it''s handling of the default values. You
might
want to see what "show fields" would give back if you specifically
gave your
columns a nil (null) default value.

The short term solution to your problem should you need the nil values would
be to override the columns method of the base class and put in the default
values you wish for the columns

For example (completely untested so don''t be surprised if
there''s bugs)

Content.rb

class Content < ActiveRecord::Base

  def columns
    unless @columns
      super
      @columns.map! { |col|
        if col.name == ''email''
          col = MysqlColumn.new(col.name, #default value#, col.sql_type,
col.null)
        end
        col
      }
    end
    @columns
  end

Obviously the #default value# would get replaced by the exact value you
wanted for the column. Note this is pretty brute force but it should work
just fine for you if you needed it. It also locks the model into MySQL due
to the need for the MysqlColumn class. It also just doesn''t have that
smooth
look of rails :)

Hope this helps you understand how it works and why

John W Higgins
wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

On 9/9/06, Jeroen Houben
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org >
wrote:
>
>
> Al Evans wrote:
> > Jeroen wrote:
> >
> >> class AddTestTable < ActiveRecord::Migration
> >>   def self.up
> >>     create_table "contents", :force => true do |t|
> >>       t.column "email", :string, :null => false
> >>     end
> >>   end
> >>
> >>   def self.down
> >>     drop_table "contents"
> >>   end
> >> end
> >>
> >> $ script/generate model Content
> >>
> >> $ script/console
> >>
> >> Loading development environment.
> >>>> Content.new.email
> >> => ""
> >>>>
> >>
> >> I just dont understand why it defaults to "" and not to
nil. Nowhere
> did
> >> I set the default to "" in my migrations file.
> >
> > It has to default to something.
>
> Well in Mysql I *can* set an integer column to NOT NULL and not specify
> a default value. It''s a valid SQL schema. I think AR should copy
this
> behaviour and not force a default zero, but I seem to stand alone in
> this. It''s no biggy really, just wanted to see what the idea
behind this
> AR behaviour was. Thanks!
>
> Jeroen
>
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
<wishdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>