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
