Testing Referential Integrity

Hey all,

I am having a little trouble getting some referential integrity tests
to work well.

Right now, I am using Postgres as my database. I have generated
migrations for my tables and ensured referential integrity by using
execute commands. All is working well at the level of the database
and application. I can get all the checks to work flawlessly if I set
up my test database by issuing “rake db:migrate RAILS_ENV=test”.

However, if I do the more traditional approach by issuing “rake
db:test:prepare and rake db:test:load,” this seems to load the
information from the schema.rb file. This file does not seem to
contain the foreign key constraints (or other db constraints, for that
matter).

Any thoughts on getting this to work properly and getting the
schema.rb file to recognize all the db checks?

I can imagine that this will be an issue at the time of production,
because the schema.rb file will not be usable for setting up the
production database. It seems to me, I would have to run the
migrations…

Thanks,

Andrew

On Sep 28, 4:44 am, Andrew P. [email protected] wrote:

However, if I do the more traditional approach by issuing “rake
db:test:prepare and rake db:test:load,” this seems to load the
information from the schema.rb file. This file does not seem to
contain the foreign key constraints (or other db constraints, for that
matter).

The ruby schema dumper doesn’t understand things that activerecord
doesn’t, which includes foreign key constraints (There’s a plugin
somewhere that adds foreign key support to active record). One way
around this is to set the schema dumper format (in environment.rb)
to :sql rather than ruby. Instead of generating schema.rb,
RAILS_ENV.sql will be generated, using your database’s tools.

Fred

Andrew P. wrote:
[…]

I can imagine that this will be an issue at the time of production,
because the schema.rb file will not be usable for setting up the
production database.

What do you mean, “at time of production”? Are you really planning to
deploy to production only after everything is done? If so, you’re
setting yourself up for integration hell. You should be deploying to a
production server (or at least a staging server) quite frequently.
Don’t wait.

It seems to me, I would have to run the
migrations…

You should be running the migrations as you deploy each new version.
(But you’re right, that’s not how you should set up the DB from
scratch.)

Thanks,

Andrew

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Frederick C. wrote:

On Sep 28, 4:44�am, Andrew P. [email protected] wrote:

However, if I do the more traditional approach by issuing “rake
db:test:prepare and rake db:test:load,” this seems to load the
information from the schema.rb file. �This file does not seem to
contain the foreign key constraints (or other db constraints, for that
matter).

The ruby schema dumper doesn’t understand things that activerecord
doesn’t, which includes foreign key constraints (There’s a plugin
somewhere that adds foreign key support to active record).

That would be foreign_key_migrations. You should definitely be using
this rather than writing your foreign key constraints in execute
statements.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]