In development and production, I've got postgresql constraints that prevent deleting a CaseManager if there is a Client that belongs to that CaseManager.
In unit tests...and obviously in my testing db, those restrictions don't get added.
Is it wrong to test for deleting dependent records in unit tests?
Craig
Craig White wrote:
In development and production, I've got postgresql constraints that prevent deleting a CaseManager if there is a Client that belongs to that CaseManager.
In unit tests...and obviously in my testing db, those restrictions don't get added.
Is it wrong to test for deleting dependent records in unit tests?
Craig
Craig -
Are you creating the constraints outside of your migrations? If you create your constraints in your migrations (using EXECUTE) then your test db should get built with them.
See: http://www.robbyonrails.com/articles/2005/11/11/rails-migrations-and-postgresql-constraints
Change your schema dumping to :sql - the ruby schema dumper doesn't know about foreign key constraints etc...
Fred
Change your schema dumping to :sql - the ruby schema dumper doesn't know about foreign key constraints etc...
Try just: rake test or even: rake
These cause the db:test:clone task to run. (you could do: rake db:test:clone test:units )
-Rob
Rob Biedenharn http://agileconsultingllc.com Rob@AgileConsultingLLC.com
Cayce Balara wrote:
Craig White wrote:
Is it wrong to test for deleting dependent records in unit tests?
Are you creating the constraints outside of your migrations? If you create your constraints in your migrations (using EXECUTE) then your test db should get built with them.
And to answer the question: Yes, test it. Tests could cover every moving part.
Better, write a test that fails, before you write this EXECUTE logic to pass it.
(But why not just use :dependent => :destroy?)
Craig White wrote:
psql:db/development_structure.sql:2071: ERROR: constraint "fk_cp_case_manager" for relation "clients" already exists
and this constraint does exist in development db and production db but still doesn't exist in test db.
rake RAILS_ENV=test db:migrate:reset
?
(And is the RAILS_ENV=test needed?)
The test database is often a clone of the development schema, so maybe you should switch your schema to .sql format like Fred said.
However, I would never put business logic in the schema if this would prevent me from using SQLite3 to run super-fast tests...
Cayce Balara wrote:
> Craig White wrote:
>> Is it wrong to test for deleting dependent records in unit tests?
> Are you creating the constraints outside of your migrations? If you > create your constraints in your migrations (using EXECUTE) then your > test db should get built with them.
And to answer the question: Yes, test it. Tests could cover every moving part.
Better, write a test that fails, before you write this EXECUTE logic to pass it.
(But why not just use :dependent => :destroy?)
Craig White wrote:
> psql:db/development_structure.sql:2071: ERROR: constraint > "fk_cp_case_manager" for relation "clients" already exists > > and this constraint does exist in development db and production db but > still doesn't exist in test db.
rake RAILS_ENV=test db:migrate:reset
Craig White wrote: > In development and production, I've got postgresql constraints that > prevent deleting a CaseManager if there is a Client that belongs to that > CaseManager. > > In unit tests...and obviously in my testing db, those restrictions don't > get added. > > Is it wrong to test for deleting dependent records in unit tests? > > Craig
Craig -
Are you creating the constraints outside of your migrations? If you create your constraints in your migrations (using EXECUTE) then your test db should get built with them.
See: http://www.robbyonrails.com/articles/2005/11/11/rails-migrations-and-postgresql-constraints
> Craig White wrote: > > In development and production, I've got postgresql constraints that > > prevent deleting a CaseManager if there is a Client that belongs to that > > CaseManager. > > > > In unit tests...and obviously in my testing db, those restrictions don't > > get added. > > > > Is it wrong to test for deleting dependent records in unit tests? > > > > Craig > > Craig - > > Are you creating the constraints outside of your migrations? If you > create your constraints in your migrations (using EXECUTE) then your > test db should get built with them. > > See: > http://www.robbyonrails.com/articles/2005/11/11/rails-migrations-and-postgresql-constraints ---- Yes...all of my constraints were added inside of migrations but no, the test db tables seem to have none of the constraints but the development and production tables all do. I presume that is because the migrations were specifically executed in both modes.
In development and production, I've got postgresql constraints that prevent deleting a CaseManager if there is a Client that belongs to that CaseManager.
In unit tests...and obviously in my testing db, those restrictions don't get added.
Is it wrong to test for deleting dependent records in unit tests?
In development and production, I've got postgresql constraints that prevent deleting a CaseManager if there is a Client that belongs to
that CaseManager.In unit tests...and obviously in my testing db, those restrictions
don't get added.Is it wrong to test for deleting dependent records in unit tests?
---- OK simplifying my problem...
$ grep schema config/environment.rb # Use Active Record's schema dumper instead of SQL when creating the test database #config.active_record.schema_format = :ruby config.active_record.schema_format = :sql
so my schema_format is sql
$ rake db:schema:dump (in /home/craig/svn-new/th-db/branches/phase5)
but there's no constraints in schema.rb
because the :sql schema dumper doesn't dump into schema.rb (it dumps
into development.sql). Maybe the sql dumper for postgres is screwing
up, but it is certainly the case that with mysql this does result in
the test db having the appropriate foreign key constraints.
Fred
> >> In development and production, I've got postgresql constraints that >> prevent deleting a CaseManager if there is a Client that belongs to
>> that >> CaseManager. >> >> In unit tests...and obviously in my testing db, those restrictions
>> don't >> get added. >> >> Is it wrong to test for deleting dependent records in unit tests? > ---- > OK simplifying my problem... > > $ grep schema config/environment.rb > # Use Active Record's schema dumper instead of SQL when creating the > test database > #config.active_record.schema_format = :ruby > config.active_record.schema_format = :sql > > so my schema_format is sql > > $ rake db:schema:dump > (in /home/craig/svn-new/th-db/branches/phase5) > > but there's no constraints in schema.rb > because the :sql schema dumper doesn't dump into schema.rb (it dumps
into development.sql). Maybe the sql dumper for postgres is screwing
up, but it is certainly the case that with mysql this does result in
the test db having the appropriate foreign key constraints.
I'm not quite awake today. If i recall correctly schema:dump (by definition) does a ruby schema dump into schema.rb, clone_structure does an sql structure dump into development_structure.sql The config setting controls what is done and used when
Fred
> >> >> >>> >>>> In development and production, I've got postgresql constraints that >>>> prevent deleting a CaseManager if there is a Client that belongs to >>>> that >>>> CaseManager. >>>> >>>> In unit tests...and obviously in my testing db, those restrictions >>>> don't >>>> get added. >>>> >>>> Is it wrong to test for deleting dependent records in unit tests? >>> ---- >>> OK simplifying my problem... >>> >>> $ grep schema config/environment.rb >>> # Use Active Record's schema dumper instead of SQL when creating the >>> test database >>> #config.active_record.schema_format = :ruby >>> config.active_record.schema_format = :sql >>> >>> so my schema_format is sql >>> >>> $ rake db:schema:dump >>> (in /home/craig/svn-new/th-db/branches/phase5) >>> >>> but there's no constraints in schema.rb >>> >> because the :sql schema dumper doesn't dump into schema.rb (it dumps >> into development.sql). Maybe the sql dumper for postgres is screwing >> up, but it is certainly the case that with mysql this does result in >> the test db having the appropriate foreign key constraints. > ---- > I'm still on 1.2.6 - does this make a difference? > > I don't get a development.sql file as a result but I do get an updated > file db/schema.rb > > curiously enough... > > rake db:test:clone_structure creates a file db/ > development_structure.sql > that does indeed contain all of the constraints.
I'm not quite awake today. If i recall correctly schema:dump (by
definition) does a ruby schema dump into schema.rb, clone_structure
does an sql structure dump into development_structure.sql The config setting controls what is done and used when
> > > > > >> > >> > >>> > >>>> In development and production, I've got postgresql constraints that > >>>> prevent deleting a CaseManager if there is a Client that belongs to > >>>> that > >>>> CaseManager. > >>>> > >>>> In unit tests...and obviously in my testing db, those restrictions > >>>> don't > >>>> get added. > >>>> > >>>> Is it wrong to test for deleting dependent records in unit tests? > >>> ---- > >>> OK simplifying my problem... > >>> > >>> $ grep schema config/environment.rb > >>> # Use Active Record's schema dumper instead of SQL when creating the > >>> test database > >>> #config.active_record.schema_format = :ruby > >>> config.active_record.schema_format = :sql > >>> > >>> so my schema_format is sql > >>> > >>> $ rake db:schema:dump > >>> (in /home/craig/svn-new/th-db/branches/phase5) > >>> > >>> but there's no constraints in schema.rb > >>> > >> because the :sql schema dumper doesn't dump into schema.rb (it dumps > >> into development.sql). Maybe the sql dumper for postgres is screwing > >> up, but it is certainly the case that with mysql this does result in > >> the test db having the appropriate foreign key constraints. > > ---- > > I'm still on 1.2.6 - does this make a difference? > > > > I don't get a development.sql file as a result but I do get an updated > > file db/schema.rb > > > > curiously enough... > > > > rake db:test:clone_structure creates a file db/ > > development_structure.sql > > that does indeed contain all of the constraints. > > > I'm not quite awake today. If i recall correctly schema:dump (by
> definition) does a ruby schema dump into schema.rb, clone_structure
> does an sql structure dump into development_structure.sql > The config setting controls what is done and used when ---- OK - you're confirming what I am seeing.My problem is that running tests such as 'rake test:functionals' or 'rake test' drops the db and recreates it from schema.rb and the postgresql constraints aren't in schema.rb and don't get dumped to schema.rb so I'm struggling here.
[Please trim your quotes, to make your posts easy to read. And whoever is adding cruft to the Subject line please trim it too!]
Craig White wrote:
My problem is that running tests such as 'rake test:functionals' or 'rake test' drops the db and recreates it from schema.rb and the postgresql constraints aren't in schema.rb and don't get dumped to schema.rb so I'm struggling here.
---- OK thinking that I can just insert my constraints at the bottom of schema.rb - I am trying to run them in 'script/console test'
You are trying "too hard" to do things the wrong way. The right way is to add indexes with add_index, and then to enforce further constraints with Ruby code, not necessarily with database code.
If you simply must do things like this, do not write on schema.rb (or integrate it into your Version Controller). It is an automatic, write-only file. Same with development.sql.
execute 'ALTER TABLE ONLY assessments ADD CONSTRAINT fk_associations_personnel FOREIGN KEY (personnel_id) REFERENCES personnels(id);' NoMethodError: undefined method `execute' for #<Object:0xb809f9a8>
.execute is not a method of the Ruby God Object. It's a method of either ActiveRecord::Base or ActiveRecord::Base.connection.
but they work inside of migrations...
That's because the migrator inherits the right ActiveRecord:: stuff. But...
Testing is more important than putting this or that constraint into the database. Do whatever it takes to provide your tests with a _simple_ database that they can beat on. Leave this fine-tuning for later, after you have enough real data in your database that you can detect the real slow spots!
Craig White wrote:
>> My problem is that running tests such as 'rake test:functionals' or >> 'rake test' drops the db and recreates it from schema.rb and the >> postgresql constraints aren't in schema.rb and don't get dumped to >> schema.rb so I'm struggling here. > ---- > OK thinking that I can just insert my constraints at the bottom of > schema.rb - I am trying to run them in 'script/console test'
You are trying "too hard" to do things the wrong way. The right way is to add indexes with add_index, and then to enforce further constraints with Ruby code, not necessarily with database code.
If you simply must do things like this, do not write on schema.rb (or integrate it into your Version Controller). It is an automatic, write-only file. Same with development.sql.
- using a postgres schema for testing seems pointless and counter productive. I've given that up completely. Someone suggested sqllite for test db which does make sense and I may end up going that route.
Although there is an argument to say that your test environment should be close to the production environment. You don't want to find yourself writing code that works fine in sqlite, all tests pass etc.... but which doesn't in postgres. It's also a fact that rails validations etc... cannot guarantee integrity. Only the database can do that. And if your production environment enforces that but your tests don't then you could be building up to a problem: imagine that somewhere you accidentally leave a dangling reference. The test database has no constraints and doesn't care. The day you click that button in production postgres throws a wobbly because of a foreign key violation. I still don't get why it doesn't work though. You indicate that development_structure.sql (which is produced using pg_dump_ contains the constraints and all rake db:test:clone_structure does is pipe that file into psql so it's really odd that it's not working. If you know postgres well you could check the rake tasks to check they are invoking pg_dump and psql appropriately. With the :sql setting schema.rb should be touched at all and yet it is, which is just plain odd. Anyway, rake db:test:clone_structure should create development_structure.sql and load it into the test db, but if that's not working it's beyond me why,
Fred
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks