RSpec and PostgreSQL not playing nicely together


#1

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

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.


#2

On Tue, Nov 4, 2008 at 11:33 AM, Fernando P. removed_email_address@domain.invalid
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 D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com


#3

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

Thanks.


#4

On Tue, Nov 4, 2008 at 11:33 AM, Fernando P. removed_email_address@domain.invalid
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


#5

On Nov 04, 2008, at 5:07 pm, Fernando P. 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/


#6

Fernando P. removed_email_address@domain.invalid 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


#7

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.


#8

On Nov 04, 2008, at 10:15 pm, Mark W. 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/


#9

On Tue, Nov 4, 2008 at 1:10 PM, Fernando P. removed_email_address@domain.invalid
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


#10

On Tue, Nov 4, 2008 at 2:54 PM, Ashley M.
removed_email_address@domain.invalidwrote:

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. :slight_smile: 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