Rails - Sep 2006 - rake test:units is trying to load my schema every time

My unit tests are failing to run.  Every time I run them it fails before 
getting to the actual tests because it keeps trying to update the 
database schema (db:schema:load).  My tests were running just fine, then 
I created and new migration, updated my development database, rake 
db:test:clone_structure, and then rake test:units.  Why is rake trying 
to update my database for me?  How do I make it stop or realize that my 
test database it up to date?  I''ve checked the schema_version table,
and
it says the latest version.

Charlie

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Wed, Sep 06, 2006, Charlie Hubbard wrote:
> My unit tests are failing to run.  Every time I run them it fails before 
> getting to the actual tests because it keeps trying to update the 
> database schema (db:schema:load).  My tests were running just fine, then 
> I created and new migration, updated my development database, rake 
> db:test:clone_structure, and then rake test:units.  Why is rake trying 
> to update my database for me?  How do I make it stop or realize that my 
> test database it up to date?  I''ve checked the schema_version
table, and
> it says the latest version.
This is normal.  The tests will essentially drop your test database and
recreate it each time they''re run, in order to ensure that
they''re
working off the most current incarnation of your app.

If for some reason they''re unable to do that, it says to me something
is
broken with your project or your database.  What is the message you get
when they fail?

Ben

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

The message I keep getting is that one of my tables already exists. 
It''s the first one in my schema.  I noticed that some of my tests have 
trouble between runs when it goes to drop certain tables, and it says 
there''s data or foreign key problems.  I fgured that was the order of 
the fixtures, but I don''t know.  How does Rails know the order to drop 
things in so you don''t get foreign key constraint issues?

How can I debug this?  Is there a rake tasks that lets me drop my 
database?  Is it user permissions?  I''m logging in as root.

Charlie

Ben Bleything wrote:
> On Wed, Sep 06, 2006, Charlie Hubbard wrote:
>> My unit tests are failing to run.  Every time I run them it fails
before
>> getting to the actual tests because it keeps trying to update the 
>> database schema (db:schema:load).  My tests were running just fine,
then
>> I created and new migration, updated my development database, rake 
>> db:test:clone_structure, and then rake test:units.  Why is rake trying 
>> to update my database for me?  How do I make it stop or realize that my
>> test database it up to date?  I''ve checked the schema_version
table, and
>> it says the latest version.
> 
> This is normal.  The tests will essentially drop your test database and
> recreate it each time they''re run, in order to ensure that
they''re
> working off the most current incarnation of your app.
> 
> If for some reason they''re unable to do that, it says to me
something is
> broken with your project or your database.  What is the message you get
> when they fail?
> 
> Ben

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Wed, Sep 06, 2006, Charlie Hubbard wrote:
> The message I keep getting is that one of my tables already exists. 
> It''s the first one in my schema.  I noticed that some of my tests
have
> trouble between runs when it goes to drop certain tables, and it says 
> there''s data or foreign key problems.  I fgured that was the order
of
> the fixtures, but I don''t know.  How does Rails know the order to
drop
> things in so you don''t get foreign key constraint issues?
Well, I''m not entirely sure this is correct, but I *believe* that it
works by deleting all the tables, then cloning the development database.
Yeah, digging through the rake tasks confirms this; the test task
(through a few steps of prereqs) calles db:test:purge.
> How can I debug this?  Is there a rake tasks that lets me drop my 
> database?  Is it user permissions?  I''m logging in as root.
db:test:purge will empty your test database.

Don''t log in as root :)  Set up new users for your databases.

What database engine are you using?  Is your test database different
from your production/development databases?

Ben

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I''m using MYSQL 5.  I know I shouldn''t use root, but for
development and
testing I don''t see the harm.  Once in production I''ll use
different
users.

If it''s deleting tables how does it get the order right for deleting 
tables without violating foreign key constraints?

Ben Bleything wrote:
> On Wed, Sep 06, 2006, Charlie Hubbard wrote:
>> The message I keep getting is that one of my tables already exists. 
>> It''s the first one in my schema.  I noticed that some of my
tests have
>> trouble between runs when it goes to drop certain tables, and it says 
>> there''s data or foreign key problems.  I fgured that was the
order of
>> the fixtures, but I don''t know.  How does Rails know the order
to drop
>> things in so you don''t get foreign key constraint issues?
> 
> Well, I''m not entirely sure this is correct, but I *believe* that
it
> works by deleting all the tables, then cloning the development database.
> Yeah, digging through the rake tasks confirms this; the test task
> (through a few steps of prereqs) calles db:test:purge.
> 
>> How can I debug this?  Is there a rake tasks that lets me drop my 
>> database?  Is it user permissions?  I''m logging in as root.
> 
> db:test:purge will empty your test database.
> 
> Don''t log in as root :)  Set up new users for your databases.
> 
> What database engine are you using?  Is your test database different
> from your production/development databases?
> 
> Ben

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> What database engine are you using?  Is your test database different
> from your production/development databases?
Sorry forgot your last question.  Yes I have three seperate database for 
development, testing, and production.

Charlie

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 9/6/06, Charlie Hubbard
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Ben Bleything wrote:
> > On Wed, Sep 06, 2006, Charlie Hubbard wrote:
> >> The message I keep getting is that one of my tables already
exists.
> >> It''s the first one in my schema.  I noticed that some of
my tests have
> >> trouble between runs when it goes to drop certain tables, and it
says
> >> there''s data or foreign key problems.  I fgured that was
the order of
> >> the fixtures, but I don''t know.  How does Rails know the
order to drop
> >> things in so you don''t get foreign key constraint issues?
> >
> > Well, I''m not entirely sure this is correct, but I *believe*
that it
> > works by deleting all the tables, then cloning the development
database.
> > Yeah, digging through the rake tasks confirms this; the test task
> > (through a few steps of prereqs) calles db:test:purge.
> >
> >> How can I debug this?  Is there a rake tasks that lets me drop my
> >> database?  Is it user permissions?  I''m logging in as
root.
> >
> > db:test:purge will empty your test database.
> >
> > Don''t log in as root :)  Set up new users for your databases.
> >
> > What database engine are you using?  Is your test database different
> > from your production/development databases?
> >
> > Ben
>
>
>
> I''m using MYSQL 5.  I know I shouldn''t use root, but for
development and
> testing I don''t see the harm.  Once in production I''ll
use different
> users.
>
> If it''s deleting tables how does it get the order right for
deleting
> tables without violating foreign key constraints?
It doesn''t get the order right, basically.  You will need to specify
your fixtures in an order that will allow them to be dropped without
any problems.

DHH has said not to use database constraints [1], and as such we
continue to run into problems like these.  I''ve found your best bet is
not to use a database at all when testing, and to use mocks instead
[2].

Pat

[1] http://www.loudthinking.com/arc/000516.html
[2] http://glu.ttono.us/articles/2006/09/02/mocking-models

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Thanks.  After I did a rake db:test:purge is corrected itself and was 
happy again.  I guess whenever I do a db:test:clone_structure that 
causes the unit test framework to be unhappy.

I''m afraid I don''t buy DHH''s opinion on constraints. 
I too advocate for
application database architecture and laughed at the 90210 joked he said 
because he''s right it''s the old way of thinking about business
integration.  But, I''m afraid constraints are an imporant thing and 
rails should learn to work with them.  The biggest argument I have for 
adding constraints to your data is so that you''ll know when something
is
violating your data.  Does your program work because you added 
constraints?  No that''s not the point of them.  At least
you''ll know
when you aren''t working properly and the exception stack trace will 
point you to the offender fairly quickly.

For now I''ll just keep adding my fixtures in the right order.  Actually
I''m getting pretty sick of fixtures as a means to communicate test
data.
There has to be a better way.

Thanks
Charlie

Pat Maddox wrote:
> On 9/6/06, Charlie Hubbard
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
>> > works by deleting all the tables, then cloning the development
database.
>> > What database engine are you using?  Is your test database
different
>> If it''s deleting tables how does it get the order right for
deleting
>> tables without violating foreign key constraints?
> 
> It doesn''t get the order right, basically.  You will need to
specify
> your fixtures in an order that will allow them to be dropped without
> any problems.
> 
> DHH has said not to use database constraints [1], and as such we
> continue to run into problems like these.  I''ve found your best
bet is
> not to use a database at all when testing, and to use mocks instead
> [2].
> 
> Pat
> 
> [1] http://www.loudthinking.com/arc/000516.html
> [2] http://glu.ttono.us/articles/2006/09/02/mocking-models

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---