Question

Expérimenté avec Rails / ActiveRecord 2.1.1

  • Vous créez une première version avec (par exemple) ruby ??script \ generate titre du produit d'échafaudage: description de chaîne: texte image_url: chaîne
  • Ceci crée (par exemple) un fichier de migration appelé 20080910122415_create_products.rb
  • Vous appliquez la migration avec rake db: migrate
  • Maintenant, vous ajoutez un champ à la table des produits avec le script ruby ??\ générer la migration prix add_price_to_product: décimal
  • Ceci crée un fichier de migration appelé 20080910125745_add_price_to_product.rb
  • Si vous essayez de lancer rake db: migrate, la première migration sera inversée, pas la suivante! Ainsi, votre table de produits sera détruite!
  • Mais si vous utilisiez rake seul, cela vous aurait dit qu'une migration était en attente

Veuillez noter que l'application de rake db: migrate (une fois le tableau détruit) appliquera toutes les migrations dans l'ordre.

La seule solution que j'ai trouvée consiste à spécifier la version de la nouvelle migration comme suit:

rake db:migrate version=20080910125745

Je me demande donc: est-ce un nouveau comportement attendu?

Était-ce utile?

La solution

Vous devriez pouvoir utiliser

rake db:migrate:up 

pour le forcer à avancer, mais vous risquez alors de manquer des migrations entrelacées d'autres personnes de votre équipe

si vous exécutez

rake db:migrate 

deux fois, il réappliquera toutes vos migrations.

Je rencontre le même comportement sous Windows avec SQLite, il s’agit peut-être d’un bogue spécifique à un tel environnement.

Modifier : j'ai trouvé pourquoi. Dans la tâche railstie database.rake, vous avez le code suivant:

desc "Migrate the database through scripts in db/migrate. Target specific version with VERSION=x. Turn off output with VERBOSE=false."
task :migrate => :environment do
  ActiveRecord::Migration.verbose = ENV["VERBOSE"] ? ENV["VERBOSE"] == "true" : true
  ActiveRecord::Migrator.migrate("db/migrate/", ENV["VERSION"] ? ENV["VERSION"].to_i : nil)
  Rake::Task["db:schema:dump"].invoke if ActiveRecord::Base.schema_format == :ruby
end

Puis, dans mon environnement, les variables que j'ai

echo %Version% #=> V3.5.0f

en rubis

ENV["VERSION"] # => V3.5.0f
ENV["VERSION"].to_i #=>0 not nil !

ainsi les appels de tâches de rake

ActiveRecord::Migrator.migrate("db/migrate/", 0)

et dans ActiveRecord :: Migrator, nous avons:

class Migrator#:nodoc:
  class << self
    def migrate(migrations_path, target_version = nil)
      case
        when target_version.nil?              then up(migrations_path, target_version)
        when current_version > target_version then down(migrations_path, target_version)
        else                                       up(migrations_path, target_version)
      end
    end

Oui, rake db: migrate VERSION = 0 est la version longue pour rake db: migrate: down

.

Modifier : je voudrais mettre à jour le bogue du phare mais le proxy de la super société m'interdit de me connecter à cet emplacement

En attendant, vous pouvez essayer de supprimer la version avant d'appeler migrer ...

Autres conseils

Je ne suis respectueusement pas d'accord avec Tom! ceci est un bug !! V3.5.0f n'est pas une version valide pour les migrations rake. Rake ne devrait pas l'utiliser pour migrer: juste parce que ruby ??a choisi de considérer que "V3.5.0f" .to_i vaut 0 ...

Rake devrait se plaindre très fort que la VERSION n’est pas valide pour que les utilisateurs sachent ce qui se passe. (entre vous et moi, vérifier que la version est un horodatage formaté AAAAMMJJ en convertissant en entier est un peu léger)

[Merde IE6 qui ne me permettra pas de commenter! et non je ne peux pas changer de navigateur grâce aux entreprises]

Ce n'est pas le comportement attendu. J'allais suggérer de signaler ceci comme un bug sur le phare, mais je vois que vous avez déjà terminé ! Si vous fournissez des informations supplémentaires (y compris la version OS / database / ruby), je les examinerai.

Jean,

Merci beaucoup pour votre enquête. Vous avez raison, et en fait, je pense que vous avez découvert un bogue plus grave, le "bogue de conception" d'une espèce.

Ce qui se passe, c’est que rake récupère toutes les valeurs que vous transmettez à la ligne de commande et les stocke en tant que variables d’environnement. Les tâches de rake qui seront éventuellement appelées extrairont simplement ces valeurs de la variable d'environnement. Lorsque db: migrate interroge ENV [& VERSION "], il demande en fait le paramètre de version que vous définissez comme appelant rake. Lorsque vous appelez rake db: migrate, vous ne transmettez aucune version.

Mais nous avons une variable d’environnement appelée VERSION qui a été définie à d’autres fins par un autre programme (je ne sais pas encore lequel). Et les gars derrière rake (ou derrière database.rake) n'ont pas pensé que cela se produirait. C'est un bug de conception. Au moins, ils auraient pu utiliser des noms de variables plus spécifiques, tels que "RAKE_VERSION". ou " RAKE_PARAM_VERSION " au lieu de simplement "VERSION".

Tom, je ne vais certainement pas fermer mais modifier mon rapport de bogue sur le phare pour refléter ces nouvelles découvertes.

Et merci encore Jean pour votre aide. J'ai posté ce bug sur le phare il y a 5 jours et je n'ai toujours pas de réponse!

Rollo

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top