This project is archived and is in readonly mode.

#5849 ✓invalid
James B. Byrne

Rails3 rake task db:test:prepare no longer handles stored procedures

Reported by James B. Byrne | October 20th, 2010 @ 09:29 PM

see: http://gist.github.com/636670

Prior to Rials-3 rake db:test:prepare properly included stored procedures into the test database that were found in the development and production databases. This is no longer the case.

We have PostgreSQL AR migrations that properly create functions and triggers in the development and production databases. We have tests that check that these stored procedures work as expected. With Rails-2 these tests pass. In Rails-3 they do not. If we run rake db:test:prepare from the rails-2 version of the app and then run all the tests in the Rails-3 version (without using rake) then all the tests pass. If we then run rake db:test:prepare in the Rails-3 version and rerun the tests (again without rake) then those tests dependent upon the stored procedures fail.

This situation has no effect on production or development since the migrations still work as expected but it creates a considerable burden on the test environment.

Comments and changes to this ticket

  • Michael Koziarski

    Michael Koziarski October 22nd, 2010 @ 09:34 PM

    • State changed from “new” to “invalid”
    • Importance changed from “” to “Low”

    You need to set config.active_record.schema_format = :sql

    That will then use the db-specific schema dumping/loading tools and can load every database specific thing you want to throw at it.

  • James B. Byrne

    James B. Byrne October 23rd, 2010 @ 02:54 PM

    • Tag cleared.

    Forgot about that one. Thanks for the reminder. We just switched over to Rails3 and missed this in the configuration changes.

  • James B. Byrne

    James B. Byrne October 25th, 2010 @ 03:37 PM

    Well, it seems that while the advice given is absolutely correct, it is incomplete.

    In Rails 3 the default location for the configuration setting config.active_record.schema_format = :sql is config/environments/test.rb. At least that is where the rails project generator template puts it. However, the test.rb configuration file is not used when one runs rake db:test:prepare and RAILS_ENV is set to "development".

    It seems to me counter-intuitive that running a rake task in the default (development) environment, without RAILS_ENV set should behave differently than when RAILS_ENV is explicitly set to "development". In fact, it seems odd to me that the test.rb configuration should ever be used outside of an actual test run.

    I realize that there is a conceptual crossover here and that preparing for a test is not far removed from performing the test itself. I nonetheless am concerned that mixing the two in this way defeats the purpose of splitting things out into different environment files. If the intent is that running rake db:test:prepare creates the test database differently for each environment that the rake task might be run in then at the very least the default location for this setting should be development.rb and not test.rb. If the intent is that the default treatment is found in test.rb but that this value can be overridden in specific environments then the default should be taken from test.rb first and only overridden if it is also specified in the actual environment configuration file.

    The present configuration and usage is somewhat contradictory.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Referenced by

Pages