Question

J'ai deux machines: une machine de développement et une machine de production. Lorsque j'ai introduit mon application rails sur le serveur de production, je n'ai rencontré aucun problème. J'ai simplement importé schema.rb en exécutant rake db: schema: load RAILS_ENV = production. Tout allait bien.

Alors, sur ma machine de développement, j'ai apporté quelques modifications supplémentaires et une autre migration, puis j'ai copié la nouvelle application sur la machine de production. J'ai ensuite essayé de mettre à jour la base de données en exécutant rake db: migrate RAILS_ENV = production. Je reçois l'erreur suivante: "Il existe déjà un objet nommé 'schema_migrations' dans la base de données."

Je me dis, tu ne plaisantes pas, tu l'as créé! J'ai couru trace sur rake et il semble que rake pense que c'est la première fois qu'il coure. Cependant, en analysant ma table 'schema_migrations' sur ma machine de développement et ma machine de production, vous pouvez voir qu'il existe une différence d'une migration, à savoir celle que je souhaite migrer.

J'ai également essayé de définir explicitement le numéro de version, mais cela ne fonctionne pas non plus.

Avez-vous des idées pour mettre mon serveur de production à jour?

Mise à jour:

Permettez-moi de commencer en disant que je ne peux pas simplement "supprimer" la base de données. C'est un serveur de production qui contient déjà un peu plus de 100 000 enregistrements. Que se passe-t-il si un problème similaire se produit à l'avenir? Dois-je simplement supprimer la table chaque fois qu'un problème de base de données survient? Cela pourrait fonctionner cette fois-ci, mais cela ne semble pas être une solution pratique à long terme à tous les problèmes de base de données. Je doute que le problème que je rencontre maintenant soit unique à moi.

  1. Cela ressemble à la table 'schema_info' et à la table 'schema_migrations' sont les mêmes. Dans ma configuration, je n'ai que des 'schema_migrations'. Comme indiqué précédemment, la différence entre la table 'schema_migrations' sur le serveur de production et la machine de développement correspond à un seul enregistrement. En d'autres termes, l'enregistrement contenant le numéro de version du changement que je souhaite migrer.

  2. Dans le livre que j'ai lu, "Simply Rails 2", il est indiqué que, lors du premier passage sur un serveur de production, au lieu d'exécuter rake db: migrate, il suffit d'exécuter rake: db: schema: load.

  3. Si cela compte, j'utilise Rails version 2.1.

Pas de solution correcte

Autres conseils

C’est une hypothèse, j’admets: je pense que, parce que vous avez d’abord exécuté db: schema: load au lieu de db: migrate dans votre environnement de production, vous avez obtenu la structure de votre base de données, mais pas les données migrées. table schema_info. Alors maintenant, lorsque vous exécutez la migration dans l'environnement de production, il n'y a pas de données dans schema_info, raison pour laquelle migrate pense qu'elle n'a pas encore été exécutée (car ce n'est pas le cas).

Cela dit ... vous dites que vous avez regardé dans les "schema_migrations". table, et qu’il existe une différence d’une version de dev à la production ... Je n’ai pas entendu parler de cette table, bien que j’ai quelques mois de retard sur ma version rails. Vous pourriez peut-être essayer de créer un " schema_info " tableau dans l’environnement de production, avec une "version" " unique colonne et ajoutez une ligne avec la version sur laquelle vous pensez que votre environnement de production est activé.

Si vous obtenez "Il existe déjà un objet nommé" schema_migrations "dans la base de données." message d'erreur alors je soupçonne que vous utilisez MS SQLServer comme base de données? (Cela ressemble à un message d'erreur de MS SQL Server)

Si oui, quel adaptateur de base de données ActiveRecord vous utilisez? (Quel est votre fichier database.yml, quels gems avez-vous installé pour accéder à la base de données MS SQL Server?)

Actuellement, il semble que Rails ne trouve pas la table schema_migrations dans le schéma de production et tente donc de la créer. Cette création échoue avec un message d'erreur de base de données. La raison en est probablement des majuscules / minuscules dans le nom de la table schema_migrations. Autant que je sache, les identifiants de MS SQL Server sont sensibles à la casse.

En fonction du système utilisé en production, j'ai déjà rencontré des cas où not ne fonctionne pas:

rake db:migrate RAILS_ENV=production

Mais là où ça marche:

RAILS_ENV=production rake db:migrate

Bizarre, je sais, mais cela vaut la peine de l'essayer pour voir si cela fait une différence.

En ce qui concerne votre mise à jour:

  1. Je ne comprends pas quelle est la différence entre vos migrations schema_production et la version dev. Existe-t-il un enregistrement dans les deux tables (il ne devrait y avoir qu'une colonne, "version", à droite) ou existe-t-il un seul enregistrement dans la base de données dev et zéro en production? S'il n'y a aucun enregistrement dans la table de production, procédez comme suit:

    ActiveRecord :: Base.connection.execute ("INSERT schema_migrations (version) VALUES (# {mon numéro de version sur lequel la production est supposée être}})"

  2. Vous pouvez également essayer de supprimer totalement la table schema_migrations en production:

    ActiveRecord :: Base.connection.execute ("DROP TABLE schema_migrations")

    Ensuite, relancez rake db: migrate RAILS_ENV = production . Cela exécutera les migrations à partir de la version 1, ce qui n’est probablement pas ce que vous cherchez.

  3. Vous pouvez également démarrer une session IRB dans votre environnement de production en effectuant une opération "Requiert" et "Requiert". ou " charger " (Je ne me souviens jamais lequel du fichier de migration que vous souhaitez charger, ou si cela importe), puis appelez MyMigrationClass.up . Vous devrez ensuite définir manuellement le numéro de version dans la table schema_migrations, car vous auriez toujours le problème à l'avenir, mais en tant que type de correction rapide, cela fonctionnerait.

Je voudrais simplement supprimer la base de données, l'ajouter à nouveau et exécuter rake rb: migrate. Brad a raison de dire que lorsque vous avez exécuté le chargement du schéma, aucun enregistrement n'a été placé dans la table schema_migrations.

Ceci est bien entendu plus compliqué s’il existe des données que vous ne pouvez pas perdre sur le serveur de production. Vous pouvez obtenir les tâches de sauvegarde rake (vous ne savez pas si cela fait partie du coeur ou non), puis exécuter rake db: backup: écrire sur votre base de données de production, puis après avoir mis à jour les migrations en production, exécutez rake db: sauvegarde: lire.

schema_info provient d'une ancienne version de Rails. schema_migrations est le nouvel enfant du bloc. Vous devriez pouvoir supprimer la table schema_info car elle ne sera plus utilisée. Vous voudrez probablement rechercher tout problème associé à ce changement de nom.

rake db: schema: load chargera la structure de la base de données à partir de schema.rb. Ce fichier est la représentation actuelle de la structure de la base de données. Il est utilisé lorsque vous avez un schéma vide (base de données) qui nécessite la création de toutes les tables et de tous les index. Cela vous évite d'avoir à exécuter toutes les migrations. Si vous avez une base de données de production existante avec des données, vous ne voulez pas l'exécuter. Comme d’autres l’ont dit, ce serait mauvais!

Je sais que ce message a été publié il y a quelque temps, mais je suis tombé sur lui et il n'a pas vraiment été répondu. Comme il arrive sur google, voici.

Lorsque vous avez créé une base de données rake: schema: dump (ou lorsque cela a été fait pour vous par les scripts de construction), la définition de la table des migrations a été insérée dans le fichier schema.rb. À la fin du script, le processus essaiera de créer à nouveau la table, mais elle existe déjà de toute évidence. Supprimez simplement la table des migrations de schema.rb avant d'exécuter rake: schema: load et aucun message d'erreur ne se produira.

Vous devez définir le numéro de version dans le tableau des migrations pour pouvoir exécuter les migrations ultérieurement. Il est donc important de connaître également la version de votre schéma.rb ou de supprimer toutes les anciennes migrations (elles sont en toute sécurité dans votre SCM, n'est-ce pas?)

rake db:migrate RAILS_ENV=production

Utilisez la tâche db: schema: load uniquement pour la première création. Les modifications incrémentielles doivent être migrées.

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