If you haven't seen it already, there is a rails plugin that adds support for foreign-key dependencies (among other things) to the migration domain specific language (DSL): http://www.redhillonrails.org/#foreign_key_migrations Another useful plug-in is "Transactional Migrations" which automatically wraps ActiveRecord migrations inside a transaction, if your database supports transactional DDL, as Postgres does. This neatly avoids messy half-completed database migrations and the need to clean them up by hand. On 8/6/07, Michael Glaesemann <grzm@xxxxxxxxxxxxxxx> wrote: > On Aug 6, 2007, at 13:17 , Perry Smith wrote: > > > I'm using config.active_record.schema_format = :sql. I like the > > idea of constraints in the db -- I know that goes against a lot of > > rails ideas. > > I think most who choose Postgres come to the same conclusion. Though > do take care not to confuse Rails as a whole with ActiveRecord in > particular. > > > The :ruby choice does not dump and load constraints (at least not > > in the released version -- I have not verified this on edge Rails > > yet). > > I doubt it does. DHH's take on "application database" (as much- > discussed elsewhere) wouldn't make such developments a priority, if > they'd even be considered for ActiveRecord. > > > The pg_dump and psql load have one short coming. I really do not > > like warning messages. If I have a language loaded in the > > database, the psql load of the database produces two warnings > > (because I'm not loading it as postgres -- just a regular user with > > createdb privilege. > > > > I might be drifting off the original subject but, what I did to > > solve this was to hook up the create_database and drop_database and > > I have it understand the template parameter. So, now in > > database.yml, I have a template database (like foo_template) and > > foo_test is copied from foo_template -- that avoides the error > > messages and creates a test database with whatever I need in it in > > one step. > > I've considered using a similar technique for testing. There was > discussion on rails-core a few weeks ago about various migration/ > testing related issues, IIRC. Haven't gotten around to it yet as my > rake tasks and the roles I use have pretty much taken care of the > issue for me. > > > One thing I thought about over the past evening is that I could > > just beef up the :ruby schema dump and load to understand the > > couple of things I need for it to understand: constraints and > > functions But, I'm not sure what kind of quagmire I'm walking in to. > > Definitely not worth the effort. The :ruby schema dump is there only > to support the migration SQL DSL. In my opinion, if you're using SQL > not supported by the DSL, there's little reason to use it at all. > Most likely the SQL will not be entirely portable anyway (leaving > aside the point of whether or not that should even be a design goal) > so why take the time to learn another microlanguage? :) It doesn't > take much to have requirements beyond what the migration DSL > provides, as you've already discovered, and to extend the DSL in a > portable way would be quite an endeavor. Quagmire is a good word for it. > > Michael Glaesemann > grzm seespotcode net > > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
