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

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(at)seespotcode(dot)net> 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
>