Forum: Rails-core (closed, excessive spam) Problems with schema.rb?

I'm having problems (acctually diferences) in the generated databases by
Rails. Here's my database.yaml:

===== database.yaml =====
defaults: &defaults
  adapter: mysql
  encoding: utf8
  username: root
  password:
  socket: /tmp/mysql.sock

development:
  database: gemarco_development
  <<: *defaults

test:
  database: gemarco_test
  <<: *defaults

production:
  database: gemarco
  <<: *defaults
===== database.yaml =====


And the migration:

===== 20080603140348_create_creditos.rb =====
class CreateCreditos < ActiveRecord::Migration
  def self.up
    create_table :creditos do |t|
      t.decimal :valor
    end
  end

  def self.down
    drop_table :creditos
  end
end
===== 20080603140348_create_creditos.rb =====


After applying the migrations I have:

mysql> use gemarco_development;
Database changed
mysql> describe creditos;
+-------+---------------+------+-----+---------+----------------+
| Field | Type          | Null | Key | Default | Extra          |
+-------+---------------+------+-----+---------+----------------+
| id    | int(11)       | NO   | PRI | NULL    | auto_increment |
| valor | decimal(10,0) | YES  |     | NULL    |                |
+-------+---------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

That's OK for me. decimal(10,0) is what I was expecting. But the same
isn't true for the test database:

mysql> use gemarco_test;
Database changed
mysql> describe creditos;
+-------+------------+------+-----+---------+----------------+
| Field | Type       | Null | Key | Default | Extra          |
+-------+------------+------+-----+---------+----------------+
| id    | int(11)    | NO   | PRI | NULL    | auto_increment |
| valor | bigint(10) | YES  |     | NULL    |                |
+-------+------------+------+-----+---------+----------------+
2 rows in set (0.01 sec)

It's showing bigint(10). I looked at schema.rb and this is what a found:

===== schema.rb =====
...
  create_table "creditos", :force => true do |t|
    t.integer "valor", :limit => 10, :precision => 10, :scale => 0
  end
...
===== schema.rb =====

t.integer with :precision and :scale? What's wrong?

I readed the documentation and found that:
    * MySQL: :precision [1..63], :scale [0..30]. Default is (10,0).

This is what happening in the development environment, but not in the
test environment.

I generated the development database with "rake db:migrate" and the test
database with "rake test:units".

PS: When I specify the :precision and the :scale in the migration
everything's OK.

rails --version
Rails 2.1.0

mysql --version
mysql  Ver 14.12 Distrib 5.0.60, for pc-linux-gnu (i686) using readline
5.2

On Thu, Jun 5, 2008 at 11:07 AM, Leonel Freire <
ruby-forum-incoming@andreas-s.net> wrote:

> | Field | Type          | Null | Key | Default | Extra          |
> Database changed
> mysql> describe creditos;
> +-------+------------+------+-----+---------+----------------+
> | Field | Type       | Null | Key | Default | Extra          |
> +-------+------------+------+-----+---------+----------------+
> | id    | int(11)    | NO   | PRI | NULL    | auto_increment |
> | valor | bigint(10) | YES  |     | NULL    |                |
> +-------+------------+------+-----+---------+----------------+
> 2 rows in set (0.01 sec)
>
> It's showing bigint(10).


I assume you ran the migration by running rake db:migrate.  This only
affects the development environment unless you specify the RAILS_ENV
environment value to override it.  (rake RAILS_ENV=test db:migrate)

But you can also use rake db:test:prepare to copy the schema of the
development environment from the development database to the test 
database.


--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On Fri, Jun 6, 2008 at 5:47 PM, Rick DeNatale <rick.denatale@gmail.com> 
wrote:
> I assume you ran the migration by running rake db:migrate.

He said as much in his message.

> But you can also use rake db:test:prepare to copy the schema of the
> development environment from the development database to the test database.

He said he ran rake test:units to get his test db up to date, which
would have fired db:test:prepare via prereq.

Lionel, just to run the whole thing cleanly, can you try doing rake
db:drop db:create db:migrate db:test:prepare and then check schema.rb
to see if it still wants to create an integer column even though your
migration creates a decimal column?

When you said everything was ok when you specified the precision and
scale in the migration, were you specifying :precision => 10, :scale
=> 0?

Out of curiosity, (and I know it's the default, but) why would one
want a decimal column with a scale of zero?
-hume.

Just to make it more clear, I started a new Rails project as described 
here:

http://rails.lighthouseapp.com/projects/8994/ticke...

> Lionel, just to run the whole thing cleanly, can you try doing rake
> db:drop db:create db:migrate db:test:prepare and then check schema.rb
> to see if it still wants to create an integer column even though your
> migration creates a decimal column?

This time I used 'rake db:test:prepare', as Rick said, and got the same 
results.

> When you said everything was ok when you specified the precision and
> scale in the migration, were you specifying :precision => 10, :scale
> => 0?

No. ':precision => 9, :scale => 2'. But I did the same test again, this 
time specifying ':precision => 10, :scale => 0' and, one more time, I 
got the same results. I think this could be something with MySQL or the 
communication between MySQL and Rails. I mean, DECIMAL(10,0) and 
BIGINT(10) differ only by the scale information and maybe this is 
confusing MySQL or Rails.

> Out of curiosity, (and I know it's the default, but) why would
> one want a decimal column with a scale of zero?

Just for testing purposes. I was going to put the constraints later. ;o)

PS: LEonel, not LIonel. ;oP

Thanks for your attention. ;oD