Capistrano déployer:migration et db:migrate exécuter toutes les migrations à chaque fois
Donc, je suis diddling autour avec des rails (ruby 1.9.3p392, rails 3.2, sqlite3 db) et je suis en train de déployer l'omniprésent tutoriel du blog code pour une "production" de serveur (apache, passager, ubuntu). Mon déployer.rb ressemble à ceci:
require 'bundler/capistrano'
require 'rvm/capistrano'
load 'deploy/assets'
set :rvm_ruby_string, ENV['GEM_HOME'].gsub(/.*\//,"")
set :rvm_type, :user
set :user, 'blah'
set :application, 'railsTest'
set :domain, 'www.blah.com'
set :applicationdir, "/home/sean/public/blah.com/public"
set :scm, 'git'
set :repository, "ssh://[email protected]/home/blah/public/bla.com/public/capDep.git"
#set :git_enable_submodules, 1 # if you have vendored rails
set :branch, 'master'
set :git_shallow_clone, 1
set :scm_verbose, true
set :use_sudo, false
# roles (servers)
role :web, domain
role :app, domain
role :db, domain, :primary => true
# deploy config
set :deploy_to, applicationdir
set :deploy_via, :export
set :migrate_target, :latest
# additional settings
default_run_options[:pty] = true # Forgo errors when deploying from windows
#ssh_options[:keys] = %w(/home/blah/.ssh/id_rsa)
ssh_options[:forward_agent] = true
# if you want to clean up old releases on each deploy uncomment this:
# If you are using Passenger mod_rails uncomment this:
namespace :deploy do
task :start do ; end
task :stop do ; end
task :restart, :roles => :app, :except => { :no_release => true } do
run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
end
end
#after "deploy:update_code", "deploy:migrate"
Maintenant, je suis sûr que doit ressembler à un grand désordre chaud pour ceux qui savent ce qu'ils font avec capistrano, mais je suis une totale rube. En fin de compte, en dépit de mes insuffisances, le déploiement semble fonctionner, parce que quand je lance la suite de
cap deploy:setup
cap deploy
mon application est en place et en cours d'exécution et, juste parce que je peux, j'ai ajouter quelques lignes à une table dans la base de données via l'interface web qui a été créé pour moi par les rails. Maintenant, j'en gras et de créer une migration, l'ajout d'une colonne à une table. Je pousse mes changements de git. À ma grande horreur, quand je lance
cap deploy
TOUS les migrations sont gérées, ce qui recrée les tables, détruisant ainsi toutes mes données. J'ai répété ce douloureux processus plusieurs fois. Mon schema_migrations tableau ressemble à ceci:
20130620210004
20130620220229
20130628213331
20130628214946
20130628223002
Ce qui me manque ici?
Mise à JOUR: j'ai récemment donné @TheMahrvin est une suggestion au sujet de l'exécution de déployer:les migrations à la ligne de commande et en le retirant de la déployer.rb. Il n'a pas de travail... une fois de plus, toutes les migrations ont été exécutés. Ma muse doit avoir murmura quelque chose à mon oreille, parce que j'ai décidé de l'essayer db:migrate sur le serveur lui-même. J'ai été étonné de voir cette sortie après l'exécution "râteau":
20130717230110 CreateHighScores
20130717230342 CreateGames
20130717231041 AddGameTypeToGame
20130717233707 AddGamePublisherToGame
20130717234124 AddGameRatingToGame
20130731210558 AddGameMechanicToGame
Seulement les dernières migrations devrait être en attendant. Alors, peut-être que ce n'est pas un problème avec Capistrano à tous (j'ai mis à jour le titre de cette question afin de refléter que). Alors, pourquoi les migrations antérieures encore être considéré comme en attente? Je sais qu'ils ont été exécutés dans le passé, à la fois parce que j'ai vu dans la sortie et de vérifier l'db schéma après ils ont couru.
Mise à JOUR #2: l'Installation d'une autre migration et accède par ssh sur le serveur et le cd de mon chemin vers le "courant" de répertoire, qui, si je comprends capistrano (fat chance) est l'endroit où les fichiers sont. L'exécution de
bundle exec rake db:migrate:status
m':
Status Migration ID Migration Name
--------------------------------------------------
down 20130717230110 Create high scores
down 20130717230342 Create games
down 20130717231041 Add game type to game
down 20130717233707 Add game publisher to game
down 20130717234124 Add game rating to game
down 20130731210558 Add game mechanic to game
down 20130731212454 Add publish year to game
down 20130731214515 Add game rank to game
down 20130731214928 Add game abbr to game
down 20130731215749 Add crazy field to game
Je peux pas m'empêcher de penser qu'il y a quelque chose de profondément mal avec ce que je suis en train de faire.
OriginalL'auteur seanicus | 2013-06-28
Vous devez vous connecter pour publier un commentaire.
Je n'ai pas vu:
avant. Essayez de supprimer cette ligne et de l'exécution:
ou
à la place.
Le reste de votre déploiement.rb semble OK pour moi, bien que je ne sais rien à propos de la rvm/capistrano de l'intégration ou de la windows ajustement.
OriginalL'auteur A5308Y
OK, compris... mais comment quelqu'un d'autre dans le stackosphere était censé faire la même basé sur les harengs rouges dans ma question initiale est au delà de moi.
Le problème est que ma base de données de production a été mis à
Parce que c'était une base de données sqlite dans le répertoire de projet principal, c'était de gagner de hache à chaque fois que j'ai couru
Puis, quand je courrais
Il trouvera une base de données vide et penser à toutes les migrations nécessaires pour être exécuté. J'ai résolu ce problème en changeant le chemin de base de données à
Grâce à @TheMahvin et toute autre personne qui a tenté de prendre sur la tâche sans espoir de répondre à mon mal formulé la question!
H/T à cette question, qui a fait les écailles tombent de mes yeux:
Capistrano Déployer Des Lingettes Base De Données?
OriginalL'auteur seanicus
Comment avez-vous "d'ajouter quelques lignes à une table dans la db"?
Je soupçonne votre perte de données de résultats à partir d'un mélange des migrations et de votre propre db changements.
Rails attend de vous pour faire toutes les modifications de base de données via les migrations.
Il ya un certain débat sur les migrations en général dans les Rails de la communauté, mais pour l'instant (surtout si vous êtes un débutant) toujours utiliser les migrations de modifier votre base de données. De cette façon, vous avez un plan complet pour votre base de données vous permettant de déployer sur plusieurs machines à partir de zéro, sans jongler avec votre base de données et assurez-vous que d'autres contributeurs ont la même db à travailler avec.
Je ne sais pas beaucoup au sujet de ces types de fonctionnement interne, mais ce que je comprends de votre perte de données a entraîné quelque chose comme ça:
Après vos modifications manuelles Rails ne pouvait pas répondre à la db-mise en page à la suite de toute migration (via les horodateurs dans votre migrations et votre schéma respectivement) ainsi, le traitement de la db comme si c'était nouveau. Pour obtenir à l'état défini par toutes les migrations, tous d'entre eux devaient être exécutées, y compris les migrations de créer des tableaux, donc de jeter tout ce qui en eux.
J'espère que cette aide,
Andy
Ici je vais confusion des lignes et des colonnes... Qui ne devrait pas être un problème, bien sûr...
Aucune infraction, mais cela ne semble pas vraiment de sens. Rails n'est pas de déterminer votre niveau de migration en comparant la DB schéma à la suite de migrations. Il crée une table appelée
schema_migrations
, et enregistre le timestamp de chaque migration qui a été exécuté. Lorsque vous exécutezrake db:migrate
, il compare les horodateurs dansschema_migrations
avec ceux de la migration des fichiers existants dansdb/migrate
.Ne vous en faites pas. En fait je crois même que votre commentaire s'intègre avec les pièces de ma description. J'étais tout simplement dans l'obscurité la façon dont le correspondant en détail Le résultat d'une migration est identifiable par un timestamp, comme c'est le réel db-mise en page via le schéma d'horodatage. Mais oui, la mise au rancart de la partie n'a pas vraiment de sens. J'étais juste deviner. Dois-je supprimer la réponse?
OriginalL'auteur A5308Y