Mariano Kamp
2006-Jan-12 23:00 UTC
[Rails] Best Forum? Was: Migration doesn''t seem to preserve create_table options in schema
Hi, is this the best forum to answer this question? Is there any better source for information or another mailinglist to address this question to? Cheers, Mariano ---------- Forwarded message ---------- From: Mariano Kamp <mariano.kamp@gmail.com> Date: Jan 8, 2006 6:24 PM Subject: Migration doesn''t seem to preserve create_table options in schema To: rails@lists.rubyonrails.org Hi, I have the following migration (abbreviated): class Initial < ActiveRecord::Migration def self.up create_table :messages, :options => ''ENGINE=MyISAM'', :force => true do |t| t.column :id, :integer, :null => false t.column :external_id, :string, :null => false t.column :recipients_count, :integer, :default => 0 end end def self.down drop_table :messages end end When running migrate it creates the table and the schema, but it doesn''t preserve the ":options" in the test environment... ActiveRecord::Schema.define(:version => 1) do create_table "messages", <NO :OPTIONS IN HERE>:force => true do |t| t.column "external_id", :string, :default => "", :null => false t.column "from", :string, :default => "", :null => false t.column "subject", :string end end The funny thing is that this happens with the test database, not with development. In development these options are used to create the database: mysql> show create table messages; ... messages | CREATE TABLE `messages` ( `id` int(11) NOT NULL auto_increment, `external_id` varchar(255) NOT NULL, `from` varchar(255) NOT NULL, `subject` varchar(255) default NULL, `body` tinytext, `created_on` datetime default NULL, `recipients_count` int(11) default ''0'', PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 ... In test I still see "InnoDB"... Deleting the schema.rb didn''t help. environment.rb contains this: config.active_record.schema_format = :ruby test.rb doesn''t seem to contain anything that overrides that. I am also wondering when the migration for test occurs? After rake migrate nothing seems to happen to the test database, but while running my tests with rake it seems to also do the migration. Am I doing something wrong? Cheers, Mariano -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060112/b93e51cb/attachment-0001.html
Damon Clinkscales
2006-Jan-13 04:59 UTC
[Rails] Re: Best Forum? Was: Migration doesn''t seem to preserve crea
Mariano Kamp wrote:> I have the following migration (abbreviated): > > class Initial < ActiveRecord::Migration > > def self.up > create_table :messages, :options => ''ENGINE=MyISAM'', :force => true > do > |t| > t.column :id, :integer, :null => false > t.column :external_id, :string, :null => false > t.column :recipients_count, :integer, :default => 0 > end > end > > def self.down > drop_table :messages > end > endThe default on my version of mysql is myISAM, so I did your example with :options => ''ENGINE=InnoDB'' .> When running migrate it creates the table and the schema, but it doesn''t > preserve the ":options" in the test environment... > ActiveRecord::Schema.define(:version => 1) do > > create_table "messages", <NO :OPTIONS IN HERE>:force => true do |t| > t.column "external_id", :string, :default => "", :null => false > t.column "from", :string, :default => "", :null => false > t.column "subject", :string > end > > endYes, I can confirm that the options are lost.> The funny thing is that this happens with the test database, not with > development. In development these options are used to create the > database: > > mysql> show create table messages; > ... > messages | CREATE TABLE `messages` ( > `id` int(11) NOT NULL auto_increment, > `external_id` varchar(255) NOT NULL, > `from` varchar(255) NOT NULL, > `subject` varchar(255) default NULL, > `body` tinytext, > `created_on` datetime default NULL, > `recipients_count` int(11) default ''0'', > PRIMARY KEY (`id`) > ) ENGINE=MyISAM DEFAULT CHARSET=latin1 > ... > > In test I still see "InnoDB"...I can''t confirm this. My test db always looks like my development db when I do the following: rake migrate VERSION=0 rake migrate VERSION=1 This sets up the development db with the table with the correct options set. Then to set the test db, all you do is run ''rake'' by itself. rake This calls clone_structure_to_test, which basically makes a copy of your development schema. Watch log/development.log while rake runs.> > I am also wondering when the migration for test occurs? After rake > migrate > nothing seems to happen to the test database, but while running my tests > with rake it seems to also do the migration.Rake by itself doesn''t actually run the migration. It makes a copy of your development database in its current form.> Am I doing something wrong?Depending on the order you ran your steps and if you used the faulty schema.rb file, you may have gotten yourself into a state that seemed to make no sense. Yes, I am saying that the schema.rb produced with your special options is faulty because it does not contain the table options. It appears to be a bug to me. I took a quick look over the bugs in Trac related to migrations and I don''t see anything like that about the db_schema_dump forgetting the table create options. You should take a look yourself and file a bug with a simple and clear example of the loss of options if you don''t find anything either. HTH, -damon http://damonclinkscales.com/ -- Posted via http://www.ruby-forum.com/.