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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Jun 5, 2008 at 11:07 AM, Leonel Freire < ruby-forum-incoming@andreas-s.net> wrote:> > I''m having problems (acctually diferences) in the generated databases by > Rails. Here''s my database.yaml: > ... > 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 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/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Just to make it more clear, I started a new Rails project as described here: http://rails.lighthouseapp.com/projects/8994/tickets/345-problems-with-mysql> 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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---