Re: pg_dump of only the structure from a client such as ruby

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