Forum: RSpec anyone able to explain logic behind "rake spec" startup (e.g. db:test:prepare => abort_if_pending_mi

D5df9fcd7ef4c3c937435d7d6adeab2a?d=identicon&s=25 Greg Hauptmann (Guest)
on 2008-11-06 10:44
(Received via mailing list)
anyone able to explain logic behind "rake spec" startup? i.e. the
below steps & why things occur when they do

Macintosh-2:myequity greg$ rake spec --trace
(in /Users/greg/source/myequity)
** Invoke spec (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
** Execute db:test:prepare
** Invoke db:test:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:load
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
** Execute spec
<cut>

thanks
204784d162fece694532d2ef5cdc5ca5?d=identicon&s=25 Hongli Lai (Guest)
on 2008-11-06 13:03
(Received via mailing list)
Greg Hauptmann wrote:
> ** Execute db:abort_if_pending_migrations
> <cut>
'spec' depends on 'db:test:prepare'. 'db:test:prepare' runs any pending
migrations on your development database, and copies the schema structure
to the test database. This is to keep the development database's
structure and the test database's structure in sync.

Almost everything you see here is invoked by 'db:test:preare'.
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2008-11-06 16:50
(Received via mailing list)
If you want to speed things up, just run spec spec. That will work
fine unless you have pending migrations that affect your specs.
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-06 16:51
(Received via mailing list)
On Thu, Nov 6, 2008 at 4:01 AM, Hongli Lai <hongli@plan99.net> wrote:

> <cut>
>>
>
> 'spec' depends on 'db:test:prepare'. 'db:test:prepare' runs any pending
> migrations on your development database, and copies the schema structure to
> the test database. This is to keep the development database's structure and
> the test database's structure in sync.
>
> db:test:prepare does not run migrations. It simply checks whether there are
any pending migrations and aborts if there are.

///ark
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-06 17:28
(Received via mailing list)
On Thu, Nov 6, 2008 at 7:31 AM, Matt Wynne <matt@mattwynne.net> wrote:


> If you want to speed things up, just run spec spec. That will work fine
> unless you have pending migrations that affect your specs.


Or if you have migrations that were applied to the dev db, but you
haven't
run db:test:prepare yet. I still get bitten by that.

///ark
D5df9fcd7ef4c3c937435d7d6adeab2a?d=identicon&s=25 Greg Hauptmann (Guest)
on 2008-11-06 22:19
(Received via mailing list)
I'm still a bit confused - I'll try to be more specific in questions:

* rake db:test:prepare - Check for pending migrations and load the test
schema
  ==> Q1. DOES NOT RUN IN PENDING MIGRATIONS TO TEST DATABASE?
  ==> Q2. RE TEST SCHEMA - ARE THE MIGRATIONS USE TO CREATE THE
DATABASE OR THE DEVELOPMENT SCHEMA FILE???
  ==> Q3. WHY DOES IT HAVE TO BE CALLED MORE THAN ONCE?

* rake db:test:load - Recreate the test database from the current
schema.rb
  ==> Q4.  WHY DO WE NEED TO LOAD FROM THE SCHEMA RATHER THAN
MIGRATIONS?  IS IT TO AVOID ANY DATA BEING LOADED BY MIGRATIONS FOR
THE TEST DATABASE?
  ==> Q5. WHY IS IT RUN MULTIPLE TIMES?

* rake db:test:purge - Empty the test database
  => Q6. WHY IS IT RUN MULTIPLE TIMES?
  => Q7. DOES IT DROP TABLES ALSO?

tks
Confused  :)
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-06 23:17
(Received via mailing list)
On Thu, Nov 6, 2008 at 1:07 PM, Greg Hauptmann <
greg.hauptmann.ruby@gmail.com> wrote:

> I'm still a bit confused - I'll try to be more specific in questions:
>
> * rake db:test:prepare - Check for pending migrations and load the test
> schema
>  ==> Q1. DOES NOT RUN IN PENDING MIGRATIONS TO TEST DATABASE?
>

Correct. It runs no migrations, period. It will abort if there are
pending
migrations for the development database.


>  ==> Q2. RE TEST SCHEMA - ARE THE MIGRATIONS USE TO CREATE THE
> DATABASE OR THE DEVELOPMENT SCHEMA FILE???
>

The development schema file, which db:test:prepare creates.


>  ==> Q3. WHY DOES IT HAVE TO BE CALLED MORE THAN ONCE?


I didn't know it did have to be called more than once. :)


> * rake db:test:load - Recreate the test database from the current schema.rb
>  ==> Q4.  WHY DO WE NEED TO LOAD FROM THE SCHEMA RATHER THAN
> MIGRATIONS?  IS IT TO AVOID ANY DATA BEING LOADED BY MIGRATIONS FOR
> THE TEST DATABASE?


The main reason, I believe, is for speed. The thinking is that there's
nothing in the test database that needs to be saved, whereas, you might
have
pseudo-real-world data in your development database that you don't want
to
repopulate. Therefore, the test db is created from scratch, but the
development (and production) dbs are migrated.


> ==> Q5. WHY IS IT RUN MULTIPLE TIMES?
>

Is that what you're seeing? I assume you're running 'rake
db:test:prepare
--trace'?

* rake db:test:purge - Empty the test database
>  => Q6. WHY IS IT RUN MULTIPLE TIMES?
>  => Q7. DOES IT DROP TABLES ALSO?


I haven't looked into those tasks, myself.

Probably the very best way to answer these questions is to have a look
at
lib/tasks/databases.rake in your Rails framework directory.

///ark
D5df9fcd7ef4c3c937435d7d6adeab2a?d=identicon&s=25 Greg Hauptmann (Guest)
on 2008-11-07 01:45
(Received via mailing list)
i run "rake spec --trace"
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-07 02:14
(Received via mailing list)
> i run "rake spec --trace"

That's not running anything twice, I think. "Invoke" is printed when the
task is called, then the tasks it depends on are invoked, then the task
is
executed. The environment task is invoked several times, but it's only
actually executed once.

///

On Thu, Nov 6, 2008 at 4:35 PM, Greg Hauptmann <
This topic is locked and can not be replied to.