Hi, I am new to Rails, I followed the cookbook tutorial, it worked fine, but when I started another tutorial called todo : when I type : http://127.0.0.1:3000/todo/new I get this error : Routing Error Recognition failed for "/todo/new" please help me. -- View this message in context: http://www.nabble.com/newbie-question-t1359958.html#a3643454 Sent from the RubyOnRails Users forum at Nabble.com.
And you have generated the scaffolding for the new model? On 3/29/06, mlotfi <majidnakit@yahoo.com> wrote:> > Hi, I am new to Rails, I followed the cookbook tutorial, it worked fine, but > when I started another tutorial called todo : > > when I type : http://127.0.0.1:3000/todo/new > > I get this error : > > Routing Error > > Recognition failed for "/todo/new" > > please help me. > -- > View this message in context: http://www.nabble.com/newbie-question-t1359958.html#a3643454 > Sent from the RubyOnRails Users forum at Nabble.com. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- -------------- Jon Gretar Borgthorsson
No I did not yet, just following the tutorial. -- View this message in context: http://www.nabble.com/newbie-question-t1359958.html#a3643868 Sent from the RubyOnRails Users forum at Nabble.com.
Hi, mlotfi <majidnakit@...> writes:> Hi, I am new to Rails, I followed the cookbook tutorial, it worked fine, but > when I started another tutorial called todo : > > when I type : http://127.0.0.1:3000/todo/newDid you create the controller called "todo"? Does it contain a method "new"? Regards
Hi, I''m new to both Rails and Ruby. I have a couple of very basic questions. 1. I have a migration for Accounts, but I need to add another field. If I simply add it to my 001_accounts.rb file, and re-run rake migrate, nothing happens. The new field doesn''t get added. I''ve been looking on the web but can''t find a good way to do this. 2. How to I prime my database after creation? I want to start out with a set of default data, and was wondering where the best place to do this is. Thanks. -- Posted via http://www.ruby-forum.com/.
On Apr 15, 2006, at 10:47 AM, John Quinley wrote:> I''m new to both Rails and Ruby. I have a couple of very basic > questions. > > 1. I have a migration for Accounts, but I need to add another > field. If > I simply add it to my 001_accounts.rb file, and re-run rake migrate, > nothing happens. The new field doesn''t get added. I''ve been looking on > the web but can''t find a good way to do this.Destroy and recreate your DB. Migrations are intended to be applied serially. The migrations system creates a table called schema_info that tracks migration version and uses it to determine which migrations need to be run.> 2. How to I prime my database after creation? I want to start out > with a > set of default data, and was wondering where the best place to do this > is.A higher numbers migration with Model.create statements. -- -- Tom Mornini
On 4/15/06, John Quinley <john@quinley.org> wrote:> Hi, > > I''m new to both Rails and Ruby. I have a couple of very basic questions. > > 1. I have a migration for Accounts, but I need to add another field. If > I simply add it to my 001_accounts.rb file, and re-run rake migrate, > nothing happens. The new field doesn''t get added. I''ve been looking on > the web but can''t find a good way to do this.Just do another migration. ruby script/generate migration AddWhateverToAccounts ..and then, in the migration: add_column :accounts, :some_column_name, :some_column_type> > 2. How to I prime my database after creation? I want to start out with a > set of default data, and was wondering where the best place to do this > is.You can use your regular models inside the migrations, as long as they already exist. ruby script/generate migration CreateDefaultData Account.create! :name => ''something'', :other_attribute => ''whatever'', :widgets => 5 If you have a lot of them, you could load them from YAML during the migration, rather than typing them all out.
Thanks guys for all your help. I ended up just dropping the database, re-creating it, and then re-running rake migrate. I added my primer to the end of the self.up method for the tables I wanted to fill. -- Posted via http://www.ruby-forum.com/.
Here here for the YAML method. Fill up your fixtures ( and remove the default ones ) and then... rake db:fixtures:load On 4/15/06, John Quinley <john@quinley.org> wrote:> Thanks guys for all your help. I ended up just dropping the database, > re-creating it, and then re-running rake migrate. I added my primer to > the end of the self.up method for the tables I wanted to fill. > > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Don''t go re-creating your DB! The whole point of Migrations is simple, manageable, incremental evolution of the schema that stays in sync on all the databases you''re running the app on. Adding or dropping tables, adding or deleting fields, all of this should be done in subsequent migrations. You have that initial migration that creates your first handful of tables. Then your next migration might just add a field. Run that migration. The one after that might add two more fields and another couple of tables. Run that migration. A later migration might add an index you forgot to create earlier, or alter the default value of a field, or replace one kind of field with another and convert the values from the old field to the new one, etc. Then when you move your app to deployment, or another developer starts working with the source on her own machine, all that''s needed to get an identical database schema on that machine is one "rake migrate". Got another development box that has a database schema several months behind? "Rake migrate" brings it up to speed by running all the migrations that haven''t been run already. So if you want to add a field to Accounts, this is when you create a new migration that adds the field. Pretty much the only time you should ever think of editing a migration that''s already been run is if you''re early in your app''s development and your schema is being so radically reworked from the ground up that you want to wipe the whole thing, drop the database, data and all, and start fresh. John Quinley wrote:> Hi, > > I''m new to both Rails and Ruby. I have a couple of very basic questions. > > 1. I have a migration for Accounts, but I need to add another field. If > I simply add it to my 001_accounts.rb file, and re-run rake migrate, > nothing happens. The new field doesn''t get added. I''ve been looking on > the web but can''t find a good way to do this. > > 2. How to I prime my database after creation? I want to start out with a > set of default data, and was wondering where the best place to do this > is. > > Thanks.-- Posted via http://www.ruby-forum.com/.
I am in the "early database changes radically" phase that you describe. I prefer to edit my earlier migrations and the type: rake migrate VERSION=0 followed by rake migrate or some combination of the above to bounce between the two migrations that matter. To me it is easier to work entirely within the rails world than to jump to the db app to drop the db and recreate it. Just my two pennies. Also, see this tip on using your models in migrations: http://rails.techno-weenie.net/tip/2006/2/23/safely_using_models_in_migrations I use this method to generate basic data for my new tables in each migration. This means I can migrate up and down my chain and always have basic development data to play around with. I also use the recipe in Rails Recipes for dumping my development data (created as described above) into my test fixtures. I think this is a very DRY approach and since migrations are Ruby I can still use techniques from YML test fixtures to generate large amounts of test data during the migration. On 4/16/06, Steve Koppelman <hatlessnyc@yahoo.com> wrote:> > Don''t go re-creating your DB! The whole point of Migrations is simple, > manageable, incremental evolution of the schema that stays in sync on > all the databases you''re running the app on. Adding or dropping tables, > adding or deleting fields, all of this should be done in subsequent > migrations. > > You have that initial migration that creates your first handful of > tables. Then your next migration might just add a field. Run that > migration. The one after that might add two more fields and another > couple of tables. Run that migration. A later migration might add an > index you forgot to create earlier, or alter the default value of a > field, or replace one kind of field with another and convert the values > from the old field to the new one, etc. Then when you move your app to > deployment, or another developer starts working with the source on her > own machine, all that''s needed to get an identical database schema on > that machine is one "rake migrate". Got another development box that has > a database schema several months behind? "Rake migrate" brings it up to > speed by running all the migrations that haven''t been run already. > > So if you want to add a field to Accounts, this is when you create a new > migration that adds the field. Pretty much the only time you should ever > think of editing a migration that''s already been run is if you''re early > in your app''s development and your schema is being so radically reworked > from the ground up that you want to wipe the whole thing, drop the > database, data and all, and start fresh. > > John Quinley wrote: > > Hi, > > > > I''m new to both Rails and Ruby. I have a couple of very basic questions. > > > > 1. I have a migration for Accounts, but I need to add another field. If > > I simply add it to my 001_accounts.rb file, and re-run rake migrate, > > nothing happens. The new field doesn''t get added. I''ve been looking on > > the web but can''t find a good way to do this. > > > > 2. How to I prime my database after creation? I want to start out with a > > set of default data, and was wondering where the best place to do this > > is. > > > > Thanks. > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060416/b49dcb61/attachment.html