Forum: RSpec RSpec and PostgreSQL not playing nicely together

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
059ed46172a087063ce26250e44c8627?d=identicon&s=25 Fernando Perez (fernando)
on 2008-11-04 17:33
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.
F86901feca747abbb5c6c020362ef2e7?d=identicon&s=25 Zach Dennis (zdennis)
on 2008-11-04 17:47
(Received via mailing list)
On Tue, Nov 4, 2008 at 11:33 AM, Fernando Perez <lists@ruby-forum.com>
wrote:
>
> --
>                ON a.attrelid = d.adrelid AND a.attnum = d.adnum
>
> 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
059ed46172a087063ce26250e44c8627?d=identicon&s=25 Fernando Perez (fernando)
on 2008-11-04 18:07
Doh! I forgot to run the migrations in the newly created DB.

Thanks.
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-04 18:17
(Received via mailing list)
>
> On Tue, Nov 4, 2008 at 11:33 AM, Fernando Perez <lists@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
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2008-11-04 18:52
(Received via mailing list)
Fernando Perez <lists@ruby-forum.com> writes:

>
> --
>                 ON a.attrelid = d.adrelid AND a.attnum = d.adnum
>
> 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
2ce9c0106b5851b2294ba5eb9f5c04bd?d=identicon&s=25 Ashley Moran (Guest)
on 2008-11-04 20:30
(Received via mailing list)
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-...



--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
059ed46172a087063ce26250e44c8627?d=identicon&s=25 Fernando Perez (fernando)
on 2008-11-04 22:10
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.
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-04 23:17
(Received via mailing list)
On Tue, Nov 4, 2008 at 1:10 PM, Fernando Perez <lists@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
2ce9c0106b5851b2294ba5eb9f5c04bd?d=identicon&s=25 Ashley Moran (Guest)
on 2008-11-05 00:01
(Received via mailing list)
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/
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-05 00:09
(Received via mailing list)
On Tue, Nov 4, 2008 at 2:54 PM, Ashley Moran
<ashley.moran@patchspace.co.uk>wrote:

>>
>
> 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
This topic is locked and can not be replied to.