> I see this issue is distilling into three separate arguments for
> migration-based test DB setup:
>
> 1. migrations (in their entirety) need testing too
I think the fact that I immediately disagree with this is a sign that
we're facing two distinct problems which require two distinct
solution
>>"You run your migrations against your development database, it's hardly as
>>bad as you're implying :)."
True, but... In development, you run the new migrations -you don't
typically tear down the DB and run all of them from the start.
Consequently, older migrations become stale and broken (
On Nov 30, 2007 10:13 AM, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
> > Many times drop and recreate the database is not works, especially when
> you
> > have some functions which
> > is beyon the ability of active_records, such as view schema, contrib
> > function in postgresql, etc.
> >
> >
> Many times drop and recreate the database is not works, especially when you
> have some functions which
> is beyon the ability of active_records, such as view schema, contrib
> function in postgresql, etc.
>
> I have wrote a post about "testing with postgresql". Hope it's meaningful.
>
> http:/
On Nov 30, 2007 4:53 AM, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
> > Josh's rake task looks like it provides a nice ability to load data
> > via Rake. But there is an inconsistent message being sent by Rails:
> >
> > Use Migrations. Use Migrations. Use Migrations.
> >
> > Except for test
> Josh's rake task looks like it provides a nice ability to load data
> via Rake. But there is an inconsistent message being sent by Rails:
>
> Use Migrations. Use Migrations. Use Migrations.
>
> Except for testing, where we'll use a limited, one-off method (schema
> dumper) ensuring that you'l
Josh's rake task looks like it provides a nice ability to load data
via Rake. But there is an inconsistent message being sent by Rails:
Use Migrations. Use Migrations. Use Migrations.
Except for testing, where we'll use a limited, one-off method (schema
dumper) ensuring that you'll never know
On 11/13/07, Stephen Touset <[EMAIL PROTECTED]> wrote:
> 1 ) What, then, is the preferred mechanism for "seed" data in the
> database? Currently, many people use migrations to insert bootstrap
> data. If schema.rb will be used for tasks like db:reset, none of this
> data will be loaded.
I've writ
I typically don't use migrations for "seed" data; instead, I use
something like "rake db:bootstrap" or something like that.
Is there a reason you prefer migrations?
--Jeremy
On Nov 14, 2007 12:29 AM, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
> > 1 ) What, then, is the preferred mechanism f
> > 1 ) What, then, is the preferred mechanism for "seed" data in the
> > database? Currently, many people use migrations to insert bootstrap
> > data. If schema.rb will be used for tasks like db:reset, none of this
> > data will be loaded.
There's a new plugin to fill that "gap", yaml_db:
http:/
On Nov 13, 2007, at 9:17 PM, Stephen Touset wrote:
>
> Reading the Rails commit logs, I see that db/schema.rb's purpose has
> been clarified. It's intended to be the authoritative location for
> your database schema, and rake tasks like db:reset use it to rebuild
> the schema rather than running
> 1 ) What, then, is the preferred mechanism for "seed" data in the
> database? Currently, many people use migrations to insert bootstrap
> data. If schema.rb will be used for tasks like db:reset, none of this
> data will be loaded.
In my app I made a folder under vendor called "data". I write r
Michael,
Please see me earlier comment and see ticket 8389 -that's the patch
for a task to support migration-based building of the test database.
-Chris
On Nov 14, 12:29 am, "Michael Koziarski" <[EMAIL PROTECTED]>
wrote:
> > 1 ) What, then, is the preferred mechanism for "seed" data in the
> >
Stephen,
Your questions are a mirror of mine. I am surprised that the emphasis
placed on migrations for building the development and production
databases does not extend to the test database.
There is a rake task proposed on ticket 8389 (http://
dev.rubyonrails.org/ticket/8389) that addresses th
On Nov 13, 2007 8:17 PM, Stephen Touset <[EMAIL PROTECTED]> wrote:
> Reading the Rails commit logs, I see that db/schema.rb's purpose has
> been clarified. It's intended to be the authoritative location for
> your database schema, and rake tasks like db:reset use it to rebuild
> the schema rather
> 1 ) What, then, is the preferred mechanism for "seed" data in the
> database? Currently, many people use migrations to insert bootstrap
> data. If schema.rb will be used for tasks like db:reset, none of this
> data will be loaded.
For a production database, migrations are the obvious option.
16 matches
Mail list logo
