rspec users - Nov 2008 - RSpec and PostgreSQL not playing nicely together

Here is a very simple spec:
--
require File.expand_path(File.dirname(__FILE__) +
''/../spec_helper'')

describe Product, "The Product model" do

  describe "When a new blank product object gets created" do
    before(:each) do
      @product = Product.new
    end

    it "should not be valid" do
      @product.should_not be_valid
      @product.errors.on(:title).should_not be_nil
      # plenty other errors to display...
    end
  end
end
--

And here is the error message when I run this spec:
--
spec product_spec.rb
F

1)
ActiveRecord::StatementInvalid in ''Product The Product model When a new
blank product object gets created should not be valid''
PGError: ERROR:  relation "products" does not exist
:             SELECT a.attname, format_type(a.atttypid, a.atttypmod),
d.adsrc, a.attnotnull
              FROM pg_attribute a LEFT JOIN pg_attrdef d
                ON a.attrelid = d.adrelid AND a.attnum = d.adnum
             WHERE a.attrelid = ''products''::regclass
               AND a.attnum > 0 AND NOT a.attisdropped
             ORDER BY a.attnum
./product_spec.rb:7:in `new''
./product_spec.rb:7:

Finished in 1.025511 seconds

1 example, 1 failure
--

I don''t understand why RSpec is trying to look for some kind of
relation. In the spec I am simply calling Product.new

This spec worked perfectly with MySQL.
-- 
Posted via http://www.ruby-forum.com/.

On Tue, Nov 4, 2008 at 11:33 AM, Fernando Perez <lists at ruby-forum.com>
wrote:
> Here is a very simple spec:
> --
> require File.expand_path(File.dirname(__FILE__) +
''/../spec_helper'')
>
> describe Product, "The Product model" do
>
>  describe "When a new blank product object gets created" do
>    before(:each) do
>      @product = Product.new
>    end
>
>    it "should not be valid" do
>      @product.should_not be_valid
>      @product.errors.on(:title).should_not be_nil
>      # plenty other errors to display...
>    end
>  end
> end
> --
>
> And here is the error message when I run this spec:
> --
> spec product_spec.rb
> F
>
> 1)
> ActiveRecord::StatementInvalid in ''Product The Product model When
a new
> blank product object gets created should not be valid''
> PGError: ERROR:  relation "products" does not exist
> :             SELECT a.attname, format_type(a.atttypid, a.atttypmod),
> d.adsrc, a.attnotnull
>              FROM pg_attribute a LEFT JOIN pg_attrdef d
>                ON a.attrelid = d.adrelid AND a.attnum = d.adnum
>             WHERE a.attrelid = ''products''::regclass
>               AND a.attnum > 0 AND NOT a.attisdropped
>             ORDER BY a.attnum
> ./product_spec.rb:7:in `new''
> ./product_spec.rb:7:
>
> Finished in 1.025511 seconds
>
> 1 example, 1 failure
> --
>
> I don''t understand why RSpec is trying to look for some kind of
> relation. In the spec I am simply calling Product.new
>
> This spec worked perfectly with MySQL.
I am going to go out on a limb and say that I don''t think this is an
RSpec problem. Outside of the spec, if you launch script/console in
both development and test environments, when you do Product.new, do
you have any issues?


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

Doh! I forgot to run the migrations in the newly created DB.

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

>
> On Tue, Nov 4, 2008 at 11:33 AM, Fernando Perez <lists at
ruby-forum.com>
> wrote:
>
> >      @product = Product.new
>
> > PGError: ERROR:  relation "products" does not exist
>
> > I don''t understand why RSpec is trying to look for some kind
of
> > relation. In the spec I am simply calling Product.new
>
PostgreSQL uses the term ''relation'' for
''table'' (hence the term ''relational
database''). Some folks think that a relation is a relationship between
one
table and another, via a shared column value, or key. However, a relation is
actually the relationship between the values of the columns in a the rows of
a table. A database consists of a set of these relations, each of which
satisfies a given logical statement, or predicate. For example, your
products table is set of related columns and rows such that every row
corresponds to a "product" in your system, whose column values match
attributes of that product.

My first guess as to your problem is that you need to run ''rake
db:migrate''.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081104/627b5a00/attachment.html>

Fernando Perez <lists at ruby-forum.com> writes:
> Here is a very simple spec:
> --
> require File.expand_path(File.dirname(__FILE__) +
''/../spec_helper'')
>
> describe Product, "The Product model" do
>
>   describe "When a new blank product object gets created" do
>     before(:each) do
>       @product = Product.new
>     end
>
>     it "should not be valid" do
>       @product.should_not be_valid
>       @product.errors.on(:title).should_not be_nil
>       # plenty other errors to display...
>     end
>   end
> end
> --
>
> And here is the error message when I run this spec:
> --
> spec product_spec.rb
> F
>
> 1)
> ActiveRecord::StatementInvalid in ''Product The Product model When
a new
> blank product object gets created should not be valid''
> PGError: ERROR:  relation "products" does not exist
> :             SELECT a.attname, format_type(a.atttypid, a.atttypmod),
> d.adsrc, a.attnotnull
>               FROM pg_attribute a LEFT JOIN pg_attrdef d
>                 ON a.attrelid = d.adrelid AND a.attnum = d.adnum
>              WHERE a.attrelid = ''products''::regclass
>                AND a.attnum > 0 AND NOT a.attisdropped
>              ORDER BY a.attnum
> ./product_spec.rb:7:in `new''
> ./product_spec.rb:7:
>
> Finished in 1.025511 seconds
>
> 1 example, 1 failure
> --
>
> I don''t understand why RSpec is trying to look for some kind of
> relation. In the spec I am simply calling Product.new
>
> This spec worked perfectly with MySQL.
Highly doubt it''s an RSpec problem.  Just looks like you
didn''t create
the table.  Try "rake db:migrate db:test:prepare"

Pat

On Nov 04, 2008, at 5:07 pm, Fernando Perez wrote:
> Doh! I forgot to run the migrations in the newly created DB.
Hi Fernando

I used to do this all the time, so I made a db:migrate:all task[1]  
that means you don''t have to remember which version which DB is on.   
Mine is for Merb, but I can only see a couple of lines that should  
need changing for Rails.  You might find it useful.

Ashley


[1]
http://aviewfromafar.net/2008/10/26/adventures-in-merbddland-3-reduce-migration-pain-with-db-migrate-all-rake-tasks



-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

Thanks Ashley. And I am sure I will forget to run migration for the test 
environment each time I make changes to it. I will create a dumb script 
that looks like:
--
RAILS_ENV=production rake db:migrate
RAILS_ENV=test rake db:migrate
...


It''s not DRY but it''s so easy to read with so little lines of
code. Well
it would be very easy to refactor.
-- 
Posted via http://www.ruby-forum.com/.

On Tue, Nov 4, 2008 at 1:10 PM, Fernando Perez <lists at ruby-forum.com>
wrote:
> Thanks Ashley. And I am sure I will forget to run migration for the test
> environment each time I make changes to it. I will create a dumb script
> that looks like:
> --
> RAILS_ENV=production rake db:migrate
> RAILS_ENV=test rake db:migrate
>
I think it''s actually simpler to do ''rake
db:test:prepare'' rather than
migrate the test database. Migrations can be a pain when you''ve only
got one
database to worry about, much less two. The db:test:prepare task extracts
the schema from the development database, drops the test database, then
builds it again with the schema script. One reason I like it is that I know
for sure that my tests are starting from a known state - empty. The other is
that I know for sure that the test db matches the dev db.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081104/d8f1c0f8/attachment.html>

On Nov 04, 2008, at 10:15 pm, Mark Wilden wrote:
> I think it''s actually simpler to do ''rake
db:test:prepare'' rather
> than migrate the test database. Migrations can be a pain when
you''ve
> only got one database to worry about, much less two. The  
> db:test:prepare task extracts the schema from the development  
> database, drops the test database, then builds it again with the  
> schema script. One reason I like it is that I know for sure that my  
> tests are starting from a known state - empty. The other is that I  
> know for sure that the test db matches the dev db.
Except, this doesn''t work if your migrations contain seed data, eg  
lookup tables.  In which case you have to compensate for this in your  
spec setups, which is a risky DRY violation.  It''s safer to get your  
test db into shape the same way you get your production one.

Ashley


-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On Tue, Nov 4, 2008 at 2:54 PM, Ashley Moran
<ashley.moran at patchspace.co.uk>wrote:
>
> On Nov 04, 2008, at 10:15 pm, Mark Wilden wrote:
>
>  I think it''s actually simpler to do ''rake
db:test:prepare'' rather than
>> migrate the test database. Migrations can be a pain when
you''ve only got one
>> database to worry about, much less two. The db:test:prepare task
extracts
>> the schema from the development database, drops the test database, then
>> builds it again with the schema script. One reason I like it is that I
know
>> for sure that my tests are starting from a known state - empty. The
other is
>> that I know for sure that the test db matches the dev db.
>>
>
> Except, this doesn''t work if your migrations contain seed data, eg
lookup
> tables.  In which case you have to compensate for this in your spec setups,
> which is a risky DRY violation.  It''s safer to get your test db
into shape
> the same way you get your production one.
>
See my response in the other thread. :) I can imagine situations in which
none of the solutions I offered would apply, but if possible I would prefer
them over depending on the contents of the test database.

We had a similar situation at work, where we thought we needed certain data
in order to test. We had all kinds of problems keeping test and development
in sync (both schema and data). A closer look showed that that data was not
in fact necessary. I''m not saying that applies in all cases, of course.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081104/5fa47881/attachment.html>