Rake db: test: préparation de la tâche de suppression des données dans la base de données de développement

À l'aide d'un simple Rails sqlite3 exemple de configuration dans mon config/database.yml pour Rails 3.2.6 application, j'ai utilisé pour réinitialiser mon développement de base de données, re-seed, et préparer mon test de la base de données simplement en effectuant:

$ rake db:reset
$ rake db:test:prepare 

Après avoir regardé cette entrée de blog sur le test d'une application Rails avec Travis CI sur les différents moteurs de base de données, j'ai pensé que je lui donnerais un essai, j'ai donc installé mysql et postgresql à l'aide de Homebrew (je suis sur mac OSX Snow Leopard), comme par le brew info instructions. J'ai installé pertinentes de pierres précieuses, et la configuration de la base de données et Travis fichiers comme suit:

Gemfile

# ...
group :development, :test do
  # ...
  gem 'sqlite3', '1.3.6'
end

group :test do
  # ...
  # Test mysql on Travis CI
  gem 'mysql2', '0.3.11'
end

group :test, :production do
  # ...
  # Test postgres on Travis CI and deploy on Heroku
  gem 'pg', '0.13.2'
end

config/database.yml

sqlite: &sqlite
  adapter: sqlite3
  database: db/<%= Rails.env %>.sqlite3

mysql: &mysql
  adapter: mysql2
  username: root
  password:
  database: my_app_<%= Rails.env %>

postgresql: &postgresql
  adapter: postgresql
  username: postgres
  password:
  database: my_app_<%= Rails.env %>
  min_messages: ERROR

defaults: &defaults
  pool: 5
  timeout: 5000
  host: localhost
  <<: *<%= ENV['DB'] || "sqlite" %>

development:
  <<: *defaults

test: &test
  <<: *defaults

production:
  <<: *defaults

cucumber:
  <<: *test

.travis.yml

language: ruby
rvm:
  - 1.9.2
  - 1.9.3
env:
  - DB=sqlite
  - DB=mysql
  - DB=postgresql
script:
  - RAILS_ENV=test bundle exec rake --trace db:migrate
  - bundle exec rake db:test:prepare
  - bundle exec rspec spec/
before_script:
  - mysql -e 'create database my_app_test'
  - psql -c 'create database my_app_test' -U postgres
bundler_args: --binstubs=./bundler_stubs

Maintenant, cependant, quand je lance rake db:resetje reçois un Couldn't drop db/development.sqlite3 message d'erreur avant le développement de la base de données est créé avec succès. Donc, il semble qu'il y a maintenant plusieurs appels à la chute de la même base de données(?). Le tracé de sortie ressemble à ceci:

$ rake db:reset --trace
** Invoke db:reset (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:reset
** Invoke db:drop (first_time)
** Invoke db:load_config (first_time)
** Invoke rails_env (first_time)
** Execute rails_env
** Execute db:load_config
** Execute db:drop
Couldn't drop db/development.sqlite3 : #<Errno::ENOENT: No such file or directory - my_app/db/development.sqlite3>
** Invoke db:setup (first_time)
** Invoke db:schema:load_if_ruby (first_time)
** Invoke db:create (first_time)
** Invoke db:load_config 
** Execute db:create
db/development.sqlite3 already exists
# ...

C'est étrange, mais au moins, le développement de la base de données est créé et les graines. Le vrai problème vient quand je lance rake db:test:prepare: bien qu'il n'y a pas de messages d'erreur, ainsi que la base de données de test n'est pas créé, les données dans le développement de la base de données est époustouflé (schéma est toujours dans le tact, tout de même). J'ai essayé de spécifier directement les Rails de l'environnement pour la commande et a obtenu:

$ rake db:test:prepare RAILS_ENV=test
You have 7 pending migrations:
20120503193649 CreateUsers
# ...
Run `rake db:migrate` to update your database then try again.

Après l'exécution de rake db:migrate RAILS_ENV=testj'ai pu courir mes tests rspec de nouveau. Donc, mon râteau commandes pour obtenir les mêmes résultats ont maintenant changé:

$ rake db:reset # (with an error)
$ rake db:migrate RAILS_ENV=test

Si je change mon config/database.yml fichier à un simple sqlite3 seule configuration, db:reset et db:test:prepare travail que j'attends.

Donc, est-ce que cela signifie que mon mysql et/ou postgresql paramètres sont à l'origine de râteau tâches à répétition et/ou de jouer avec les Rails de paramètres d'environnement? Où dois-je être à la recherche pour confirmer si mon environnement est vraiment mis en place pour travailler correctement avec ces 3 moteurs de base de données?

Modifier

À la recherche à la notes de publication pour les Rails 3.2.8.rc2j'ai trouvé un changement de ActiveRecord potentiellement liés à cette question:

• Ne définissez pas RAILS_ENV à development lors de l'utilisation de db:test:prepare et liées râteau tâches. Cela a été l'origine de la troncature du développement de la base de données lors de l'utilisation de RSpec. Dans la RC2 a été fixé à nouveau lors de l'utilisation de config.active_record.schema_format = :sql

config/application.rb a l'explication suivante:

# Use SQL instead of Active Record's schema dumper when creating the database.
# This is necessary if your schema can't be completely dumped by the schema dumper,
# like if you have constraints or database-specific column types
# config.active_record.schema_format = :sql

Mon schéma n'a pas de contraintes ou de la base de données spécifiques à des types de colonnes, donc je n'ai pas décommentez cette ligne, cependant, étant donné le contenu de la note de version, j'ai parié que RAILS_ENV défaut development pourrait être responsable pour les données supprimées dans l'environnement de développement. Donc, j'ai essayé un peu les choses et a obtenu les résultats escomptés en faisant ce que j'ai fait avant (après la mise à niveau des Rails à 3.2.8.rc2):

$ rake db:reset # (with an error)
$ rake db:test:prepare RAILS_ENV=test # (with no "pending migrations" issue)

C'est un peu mieux, mais semble toujours mal pour moi car il y a toujours une erreur avec rake db:resetet il ne fait pas de sens pour moi d'avoir à définir RAILS_ENV=test lors de l'exécution d'un râteau de commande spécialement adaptés pour la base de données de test.

Mise à jour

Il semblerait que la mise à niveau des Rails 3.2.9 résout ce problème en raison de la réparation suivante:

• Correction d'un bug où rake db:test:prepare essaie de charger la structure.sql dans la base de données de développement. Corrige #8032.

Grâce Liu + Rafael Mendonça França

Je peux maintenant encore, la réinitialisation de ma base de données de développement, de re-seed, et préparer mon test de la base de données simplement en effectuant:

$ rake db:reset
$ rake db:test:prepare 

source d'informationauteur Paul Fioravanti