I know that this topic was brought up on here earlier... but now that people have had a chance to play with Migrations a bit I''m curious as to how people are using them (if they are). I''ve always been a fan of maintaining the sql as I can check it into svn, but the idea of using a SchemaMigration file instead interests me. During development are you maintaining an initial SchemaMigration which contains the base schema (as opposed to keeping this in a .sql file) or do post people just update the database directly then do a sql_dump as needed? Josh
On Jul 11, 2005, at 7:25 PM, Josh Knowles wrote:> I know that this topic was brought up on here earlier... but now that > people have had a chance to play with Migrations a bit I''m curious as > to how people are using them (if they are). > > I''ve always been a fan of maintaining the sql as I can check it into > svn, but the idea of using a SchemaMigration file instead interests > me. > > During development are you maintaining an initial SchemaMigration > which contains the base schema (as opposed to keeping this in a .sql > file) or do post people just update the database directly then do a > sql_dump as needed? > > JoshI personally have not started a new project since migrations made their debut, but I will probably try that method on the next project I start. I''m currently maintaining a set of migrations AND a schema file and it''s getting to be a bit of a pain in the ass to keep the schema file in synch. Rake will always dump your development structure when it runs so you can just use migrations and then VC the dumped schema file if you need to do both. I''ll be "migrating" toward that method in the near future ;) As to other ways I''m using them, the come in most handy because I maintain client demos on a separate machine and migrations make it a snap to keep the db''s in synch. I also see this being useful in OSS projects where perhaps some packaging system (ahem, xal ;) can take care of running the migrations for you. Perhaps this could make developers less reluctant to make more radical changes? In short, the migrations is an excellent foundation with many possibilities. I can''t wait to see what''s next. -Scott
I''m probably in the unique (for now) position of having started a new project since Migration became available. The one thing we had a problem with is that the entire process cannot be done with Ruby since if you try to run ''rake migrate'' without having created the DB already, then it throws you an error and says the database does not exist. So you do have to create the DB itself, but after that, you never have to see SQL statements again for the rest of your project (depending of course on your application). We have code to create all the tables and fields in the first migration, then plan on making more migrations as we get into our project and find unplanned changes along the way. The code is very simple, and it''s just plain simple. See http://raildock.mytechsupport.com/ri/ActiveRecord::Migration for a beautiful documentation ;-) ....Thanks Duane Ben Robison Scott Barron wrote:> > On Jul 11, 2005, at 7:25 PM, Josh Knowles wrote: > >> I know that this topic was brought up on here earlier... but now that >> people have had a chance to play with Migrations a bit I''m curious as >> to how people are using them (if they are). >> >> I''ve always been a fan of maintaining the sql as I can check it into >> svn, but the idea of using a SchemaMigration file instead interests >> me. >> >> During development are you maintaining an initial SchemaMigration >> which contains the base schema (as opposed to keeping this in a .sql >> file) or do post people just update the database directly then do a >> sql_dump as needed? >> >> Josh > > > > I personally have not started a new project since migrations made > their debut, but I will probably try that method on the next project I > start. I''m currently maintaining a set of migrations AND a schema > file and it''s getting to be a bit of a pain in the ass to keep the > schema file in synch. Rake will always dump your development > structure when it runs so you can just use migrations and then VC the > dumped schema file if you need to do both. I''ll be "migrating" toward > that method in the near future ;) > > As to other ways I''m using them, the come in most handy because I > maintain client demos on a separate machine and migrations make it a > snap to keep the db''s in synch. I also see this being useful in OSS > projects where perhaps some packaging system (ahem, xal ;) can take > care of running the migrations for you. Perhaps this could make > developers less reluctant to make more radical changes? > > In short, the migrations is an excellent foundation with many > possibilities. I can''t wait to see what''s next. > > -Scott > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.13/47 - Release Date: 7/12/2005
Here''s my recommendation: Start a new application working only through a graphical schema editor, such as CocoaMySQL, for as long as possible. For me "as long as possible" is usually a few days at most. After that, I need to push the application to a staging server and then you start having more than one database involved. Your local one and the staging server one. Then you introduce migrations. Doing so gives you the first short period an intense amount of freedom to change, hack, and slash around the database with no friction at all. Change a field, reload and it''s there. With rake db_structure_dump, which is automatically run every time you do a "rake" to run all tests, you get the benefit of having your schema dumped to text, which can be checked into Subversion. The great gift of migrations is that you don''t loose your data as your application evolves. That affords "eating your own dog food" from a very early stage. We''ve followed this approach with Basecamp, Backpack, Tada, and our new application as well. Getting to use what you develop with real data is a great motivator. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
On 7/11/05, Josh Knowles <joshknowles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I know that this topic was brought up on here earlier... but now that > people have had a chance to play with Migrations a bit I''m curious as > to how people are using them (if they are). > > I''ve always been a fan of maintaining the sql as I can check it into > svn, but the idea of using a SchemaMigration file instead interests > me. > > During development are you maintaining an initial SchemaMigration > which contains the base schema (as opposed to keeping this in a .sql > file) or do post people just update the database directly then do a > sql_dump as needed?I haven''t had a chance to look at the latest version of the Rails book, but are Migrations covered in it?
On 7/12/05, Joe Van Dyk <joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I haven''t had a chance to look at the latest version of the Rails > book, but are Migrations covered in it?No, but the only thing http://api.rubyonrails.com/classes/ActiveRecord/Migration.html doesn''t cover currently is :limit. Also the only SQL option that is currently avaliable is :default. ie. can''t set "NOT NULL". Luckily this is quite easy to add: http://dev.rubyonrails.org/ticket/1712 One thing I think is only to be useful is the ability to split schema migration, and then also have a seperate method for populating sample or test data into the db by simply adding another "rake migrate_sample_data" target task to Rakefile. desc "Migrate the sample data according to the migrate scripts in db/data" task :migrate_sample_data => :environment do ActiveRecord::Migrator.up(File.dirname(__FILE__) + ''/db/data/'') end and populating db/data/?_data.rb with execute "INSERT statements". Then each (?) sample data version would be dependant on the same schema being loaded and dump then reload the sample data. Not perfect, and maybe some extra sugar can be added to the migration mechanism to make it better, but still useful. -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C
On 7/12/05, David Heinemeier Hansson <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Here''s my recommendation: > > Start a new application working only through a graphical schema > editor, such as CocoaMySQL, for as long as possible. For me "as long > as possible" is usually a few days at most. After that, I need to push > the application to a staging server and then you start having more > than one database involved. Your local one and the staging server one. > Then you introduce migrations. > > Doing so gives you the first short period an intense amount of freedom > to change, hack, and slash around the database with no friction at > all. Change a field, reload and it''s there. > > With rake db_structure_dump, which is automatically run every time you > do a "rake" to run all tests, you get the benefit of having your > schema dumped to text, which can be checked into Subversion. > > The great gift of migrations is that you don''t loose your data as your > application evolves. That affords "eating your own dog food" from a > very early stage. We''ve followed this approach with Basecamp, > Backpack, Tada, and our new application as well. Getting to use what > you develop with real data is a great motivator.If the database structure is contained in migrations, why would you want to keep the SQL schema in version control? Also, do you want to create a new Migration every time you want to add or change a field or table? Or can you reuse them? I''m having trouble figuring out how to go back down with Migrations. The rake migrate task only seems to go up (i.e. ActiveRecord::Migrator.up(File.dirname(__FILE__) + ''/db/migrate/'') )
On 7/13/05, Joe Van Dyk <joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> The rake migrate task only seems to go up (i.e. > ActiveRecord::Migrator.up(File.dirname(__FILE__) + ''/db/migrate/'') )I haven''t tested this, but I assume that adding another task to Rakefile is the thing to do: desc "Reverse migrate the database according to the migrate scripts in db/migrate" task :migrate_reverse => :environment do ActiveRecord::Migrator.down(File.dirname(__FILE__) + ''/db/migrate/'') end then rake mirgate_reverse will decrease the schema by one. -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C
On 7/13/05, Nicholas Lee <emptysands-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 7/13/05, Joe Van Dyk <joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > The rake migrate task only seems to go up (i.e. > > ActiveRecord::Migrator.up(File.dirname(__FILE__) + ''/db/migrate/'') ) > > I haven''t tested this, but I assume that adding another task to > Rakefile is the thing to do: > > desc "Reverse migrate the database according to the migrate scripts in > db/migrate" > task :migrate_reverse => :environment do > ActiveRecord::Migrator.down(File.dirname(__FILE__) + ''/db/migrate/'') > end > > then rake mirgate_reverse will decrease the schema by one.rake migrate VERSION=5 This will go up or down, depending on what schema version you''re at. I''m guessing that this will let you choose your database too, right? rake migrate VERSION=5 RAILS_ENV=test I do wish the command gave a little bit of feedback, such as "Migrated development environment to schema version 5." When I get some time, I''ll see about whipping up a quick patch for that. -- rick http://techno-weenie.net
On 7/13/05, Rick Olson <technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 7/13/05, Nicholas Lee <emptysands-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > On 7/13/05, Joe Van Dyk <joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > The rake migrate task only seems to go up (i.e. > > > ActiveRecord::Migrator.up(File.dirname(__FILE__) + ''/db/migrate/'') ) > > > > I haven''t tested this, but I assume that adding another task to > > Rakefile is the thing to do: > > > > desc "Reverse migrate the database according to the migrate scripts in > > db/migrate" > > task :migrate_reverse => :environment do > > ActiveRecord::Migrator.down(File.dirname(__FILE__) + ''/db/migrate/'') > > end > > > > then rake mirgate_reverse will decrease the schema by one. > > rake migrate VERSION=5 > > This will go up or down, depending on what schema version you''re at. > I''m guessing that this will let you choose your database too, right? > > rake migrate VERSION=5 RAILS_ENV=test > > I do wish the command gave a little bit of feedback, such as "Migrated > development environment to schema version 5." When I get some time, > I''ll see about whipping up a quick patch for that.I looked at the rake task and didn''t see how VERSION=5 got sent to anything. I tried it and it didn''t seem to do anything.
you need the rake file from 0.13.1 for this> I looked at the rake task and didn''t see how VERSION=5 got sent to > anything. I tried it and it didn''t seem to do anything.VERSION=5 is passed at environment variable -- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
Doh, I forgot to update my rails. I''m tracking the HEAD in vendor/rails, but forgot to do a ''rails .'' to update the infrastructure files. I thought environment variables had to be specified before the command? (i.e. ''MY_ENV_VAR=2 ./some_command'' for bash. On 7/13/05, Tobias Luetke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> you need the rake file from 0.13.1 for this > > > I looked at the rake task and didn''t see how VERSION=5 got sent to > > anything. I tried it and it didn''t seem to do anything. > > VERSION=5 is passed at environment variable > > -- > Tobi > http://www.snowdevil.ca - Snowboards that don''t suck > http://typo.leetsoft.com - Open source weblog engine > http://blog.leetsoft.com - Technical weblog >