I''ve never used migrations, and everyone on IRC calls me crazy because of that. Still have yet to get any real responses as to why I''m crazy though... I''m writing a new app now, but I don''t know the whole db schema for the entire app. Go figure, that''s just how it works. I''ll add a bunch of tables, edit tables, etc as the app chugs along. Figured that migrations would be a good way of handling this, compared to editing a schema file and having to drop and create the database every time. Migrations are also apparently good for updating production DBs, where you obviously can''t just drop them. My question is how to get started then...ideally I''d do everything in the migrations as opposed to having a SQL create script, because I don''t want to have to maintain it in two places. Can I do everything with migrations that I can with SQL, such as create serial columns and custom sequences in PostgreSQL? How about foreign key constraints? I''m just unable to find the docs for migrations really, because I''ve yet to find a lot of info on them. Some stuff in the wiki, but nothing that answers my questions. They seem to be very popular, but surely nobody''s using them if they don''t have the ability to handle things that everyone uses in their databases (auto_incremement in MySQL, etc). Can anyone answer these questions, or point me to a source for more info? Thanks, Pat
On 11/10/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''m writing a new app now, but I don''t know the whole db schema for > the entire app. Go figure, that''s just how it works. I''ll add a > bunch of tables, edit tables, etc as the app chugs along.Which, IMHO, is how you _should_ do it in most cases. YAGNI and all that jazz. ;-)> My question is how to get started then...ideally I''d do everything in > the migrations as opposed to having a SQL create script, because I > don''t want to have to maintain it in two places. Can I do everything > with migrations that I can with SQL, such as create serial columns and > custom sequences in PostgreSQL? How about foreign key constraints?AFAIK, you can do anything with migrations that you would do otherwise. If what you want to do isn''t implemented in the schema DSL, you can always execute raw SQL using the #execute method within your migration: class ExampleMigration def up execute "any sql you want" end end> I''m just unable to find the docs for migrations really, because I''ve > yet to find a lot of info on them.Did you find http://api.rubyonrails.com/classes/ActiveRecord/Migration.html ? Hope that helps. If you have more specific questions not covered by the above, feel free to ask. -- Regards, John Wilger http://johnwilger.com ----------- Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat. "I don''t know," Alice answered. "Then," said the cat, "it doesn''t matter." - Lewis Carrol, Alice in Wonderland
Hi ! 2005/11/10, Pat Maddox <pergesu@gmail.com>:> My question is how to get started then...ideally I'd do everything in > the migrations as opposed to having a SQL create script, because I > don't want to have to maintain it in two places. Can I do everything > with migrations that I can with SQL, such as create serial columns and > custom sequences in PostgreSQL? How about foreign key constraints?You can use any methods in ActiveRecord::SchemaStatement [1] to update your schema. Note the #execute method - it allows you to execute arbitrary SQL. If you target PostgreSQL, and your production DB is also on PSQL, you can use #execute to setup serial columns and custom sequences. Hope that helps ! -- François Beausoleil http://blog.teksol.info/ [1] http://api.rubyonrails.com/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> 2005/11/10, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: >> My question is how to get started then...ideally I''d do everything in >> the migrations as opposed to having a SQL create script, because I >> don''t want to have to maintain it in two places. Can I do everything >> with migrations that I can with SQL, such as create serial columns and >> custom sequences in PostgreSQL? How about foreign key constraints? > > You can use any methods in ActiveRecord::SchemaStatement [1] to update > your schema. Note the #execute method - it allows you to execute > arbitrary SQL. > > If you target PostgreSQL, and your production DB is also on PSQL, you > can use #execute to setup serial columns and custom sequences. > > Hope that helps ! > -- > François Beausoleil > http://blog.teksol.info/ > > [1] http://api.rubyonrails.com/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.htmlStill doesn''t explain why he has to use migrations for it. I think in Pat''s case, when you just execute arbitrary db specific statements it might not be as useful as with let''s say Typo, where you target more than one database and compromise on a feature set which works with all of them. In that case, all can use the same schema file. Sascha Ebach
On Fri, 2005-11-11 at 08:38 +0100, Sascha Ebach wrote:> > 2005/11/10, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > >> My question is how to get started then...ideally I''d do everything in > >> the migrations as opposed to having a SQL create script, because I > >> don''t want to have to maintain it in two places. Can I do everything > >> with migrations that I can with SQL, such as create serial columns and > >> custom sequences in PostgreSQL? How about foreign key constraints? > > > > You can use any methods in ActiveRecord::SchemaStatement [1] to update > > your schema. Note the #execute method - it allows you to execute > > arbitrary SQL. > > > > If you target PostgreSQL, and your production DB is also on PSQL, you > > can use #execute to setup serial columns and custom sequences. > > > > Hope that helps ! > > -- > > François Beausoleil > > http://blog.teksol.info/ > > > > [1] http://api.rubyonrails.com/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html > > Still doesn''t explain why he has to use migrations for it. I think in Pat''s > case, when you just execute arbitrary db specific statements it might not > be as useful as with let''s say Typo, where you target more than one > database and compromise on a feature set which works with all of them. In > that case, all can use the same schema file. > > Sascha EbachThis could work a few ways. As a PostgreSQL user, I find myself adding a few extra non-My$QL features at times. What Migrations provides is a nice framework and methodology for handling incremental changes to my schema. I''m currently using a combination of #create_table and #execute methods to achieve my evolving database schema. (things change) Having one huge schema file is nice to have for that initial import... but as changes occur, tracking what changed... in what order is nice to have a record of. So you can do this yourself through your own method of managing changes... or use the ever-so-convenient Migrations to stick these changes in. You don''t *have* to use it... but I would highly suggest that you do... or model your home-brewed process after it. My 2 cents, -Robby -- /****************************************************** * Robby Russell, Owner.Developer.Geek * PLANET ARGON, Open Source Solutions & Web Hosting * Portland, Oregon | p: 503.351.4730 | f: 815.642.4068 * www.planetargon.com | www.robbyonrails.com * Programming Rails | www.programmingrails.com *******************************************************/
How about foreign key constraints? On 11/11/05, Robby Russell <robby.lists-/Lcn8Y7Ot69QmPsQ1CNsNQ@public.gmane.org> wrote:> On Fri, 2005-11-11 at 08:38 +0100, Sascha Ebach wrote: > > > 2005/11/10, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > > >> My question is how to get started then...ideally I''d do everything in > > >> the migrations as opposed to having a SQL create script, because I > > >> don''t want to have to maintain it in two places. Can I do everything > > >> with migrations that I can with SQL, such as create serial columns and > > >> custom sequences in PostgreSQL? How about foreign key constraints? > > > > > > You can use any methods in ActiveRecord::SchemaStatement [1] to update > > > your schema. Note the #execute method - it allows you to execute > > > arbitrary SQL. > > > > > > If you target PostgreSQL, and your production DB is also on PSQL, you > > > can use #execute to setup serial columns and custom sequences. > > > > > > Hope that helps ! > > > -- > > > François Beausoleil > > > http://blog.teksol.info/ > > > > > > [1] http://api.rubyonrails.com/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html > > > > Still doesn''t explain why he has to use migrations for it. I think in Pat''s > > case, when you just execute arbitrary db specific statements it might not > > be as useful as with let''s say Typo, where you target more than one > > database and compromise on a feature set which works with all of them. In > > that case, all can use the same schema file. > > > > Sascha Ebach > > This could work a few ways. As a PostgreSQL user, I find myself adding a > few extra non-My$QL features at times. What Migrations provides is a > nice framework and methodology for handling incremental changes to my > schema. I''m currently using a combination of #create_table and #execute > methods to achieve my evolving database schema. (things change) > > Having one huge schema file is nice to have for that initial import... > but as changes occur, tracking what changed... in what order is nice to > have a record of. So you can do this yourself through your own method of > managing changes... or use the ever-so-convenient Migrations to stick > these changes in. You don''t *have* to use it... but I would highly > suggest that you do... or model your home-brewed process after it. > > My 2 cents, > > -Robby > > -- > /****************************************************** > * Robby Russell, Owner.Developer.Geek > * PLANET ARGON, Open Source Solutions & Web Hosting > * Portland, Oregon | p: 503.351.4730 | f: 815.642.4068 > * www.planetargon.com | www.robbyonrails.com > * Programming Rails | www.programmingrails.com > *******************************************************/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- First they laugh at you, then they ignore you, then they fight you. Then you win. -- Mahatma Karamchand Gandhi
On Fri, 2005-11-11 at 12:01 -0400, Leon Leslie wrote:> How about foreign key constraints?Just add a new migration for adding constraints: # db/migrate/6_add_foreign_key.rb class AddForeignKey < ActiveRecord::Migration def self.up execute "ALTER TABLE bees ADD CONSTRAINT beehive_id_fkey FOREIGN KEY (beehive_id) REFERENCES beehives (id);" end def self.down execute "ALTER TABLE bees DROP CONSTRAINT beehive_id_fkey;" end end rake migrate VERSION=6 ...adds fkey rake migrate VERSION=5 ...rolls back and removes fkey It''s useful for testing. :-) Robby -- /****************************************************** * Robby Russell, Owner.Developer.Geek * PLANET ARGON, Open Source Solutions & Web Hosting * Portland, Oregon | p: 503.351.4730 | f: 815.642.4068 * www.planetargon.com | www.robbyonrails.com * Programming Rails | www.programmingrails.com *******************************************************/