質問

開発マシンと生産マシンの2台のマシンがあります。 Railsアプリを最初に運用サーバーに持ち込んだとき、問題はありませんでした。 rake db:schema:load RAILS_ENV = productionを実行してschema.rbをインポートしました。すべてが順調でした。

それで、開発マシンで、さらにいくつかの変更と別の移行を行ってから、新しいアプリケーションを本番マシンにコピーしました。次に、rake db:migrate RAILS_ENV = productionを実行してデータベースを更新しようとしました。次のエラーが表示されます。 "データベースに「schema_migrations」という名前のオブジェクトが既に存在します。"

私は自分自身に考えている、冗談じゃないレーキ...あなたはそれを作成した!レーキでトレースを実行しましたが、レイクは初めて実行されたと考えているようです。ただし、開発マシンと本番マシンの「schema_migrations」テーブルを分析すると、1つの移行、つまり移行する移行に違いがあることがわかります。

バージョン番号を明示的に定義しようとしましたが、それでも機能しません。

本番サーバーを最新の状態にする方法についてのアイデアはありますか?

更新:

データベースを単に「ドロップ」することはできないと言って始めましょう。これは、すでに10万件を超えるレコードが記録されている運用サーバーです。同様の問題が将来発生した場合はどうなりますか?データベースの問題が発生するたびにテーブルを削除するだけですか?今回はうまくいくかもしれませんが、すべてのデータベースの問題に対する長期的な実用的な解決策とは思えません。私が今抱えている問題は私だけのものだとは思わない。

  1. 「schema_info」テーブルと「schema_migrations」テーブルは同じようです。私の設定では、「schema_migrations」しかありません。前に述べたように、実稼働サーバーと開発マシンの「schema_migrations」テーブルの違いはわずか1レコードです。つまり、移行する変更のバージョン番号を含むレコード。

  2. 「Simply Rails 2」という本から、最初に実動サーバーに移行するときは、rake db:migrateを実行する代わりに、rake:db:schema:loadを実行するだけでよいと述べています。

  3. 問題があれば、Railsバージョン2.1を使用しています。

正しい解決策はありません

他のヒント

これは推測です、私は認めます:実稼働環境でdb:migrateの代わりにdb:schema:loadを最初に実行したため、dbの構造を取得しましたが、移行したデータはschema_infoテーブル。したがって、現在、実稼働環境でマイグレーションを実行すると、schema_infoにデータがありません。そのため、migrateはまだ実行されていない(実行されていないため)と判断します。

それは...あなたは「schema_migrations」を見たと言います。テーブル、および開発から本番への1つのバージョンの違いがあります...私はそのテーブルについて聞いたことがありませんが、私は私のレールバージョンで数ヶ月遅れています。 「schema_info」を作成してみてください。単一の「バージョン」を持つ実稼働環境のテーブル列に追加し、運用環境が存在すると思われるバージョンの行を追加します。

"データベースに「schema_migrations」という名前のオブジェクトが既に存在する場合"エラーメッセージが表示された場合、データベースとしてMS SQLServerを使用していると思われますか? (これはMS SQL Serverのエラーメッセージのようです)

「はい」の場合、どのActiveRecordデータベースアダプターを使用していますか? (database.ymlファイルは何ですか、MS SQL Serverデータベースにアクセスするためにどのgemをインストールしましたか?)

現在、Railsは本番スキーマでschema_migrationsテーブルを見つけられないため、作成を試みますが、この作成はデータベースエラーメッセージで失敗します。おそらくその理由は、schema_migrationsテーブル名の大文字/小文字です-私の知る限り、MS SQL Serverの識別子は大文字と小文字が区別されます。

本番環境で使用されているシステムによっては、以下が動作しない動作する場合があります:

rake db:migrate RAILS_ENV=production

しかし、これが機能する場所:

RAILS_ENV=production rake db:migrate

風変わりな、私は知っていますが、それが違いを生むかどうかを試してみる価値があります。

更新について:

  1. 実際のschema_migrationsとdevバージョンの違いはわかりません。両方のテーブルにレコードがありますか(「バージョン」が1列だけである必要があります)、または開発DBに単一のレコードがあり、実動にレコードがありませんか?実動テーブルにレコードがゼロの場合、これを実行します。

    ActiveRecord :: Base.connection.execute(" INSERT schema_migrations(version)VALUES(#{本番環境が想定されているバージョン番号})")

  2. 別の方法として、本番環境でschema_migrationsテーブルを完全に削除することもできます。

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

    その後、 rake db:migrate RAILS_ENV = production を再実行します。ただし、バージョン1からの移行は実行されますが、これはおそらく後の作業ではありません。

  3. 別の方法として、実稼働環境でIRBセッションを開始し、「require」を実行することもできます。または&load; quot; (どのファイルが重要なのか、それが重要なのかを思い出せない)移行ファイルをロードしてから、 MyMigrationClass.up を呼び出します。引き続き問題が発生するため、schema_migrationsテーブルにバージョン番号を手動で設定する必要がありますが、クイックフィックスタイプのハックとしては機能します。

DBを削除して再度追加し、rake rb:migrateを実行します。 Bradは、スキーマのロードを実行したときに、schema_migrationsテーブルにレコードを入れなかったことは正しいです。

もちろん、運用サーバー上で失うことができないデータがある場合、これはより複雑です。 rakeバックアップタスクを取得し(コアの一部であるかどうかは不明)、運用データベースでrake db:backup:writeを実行し、運用環境で最新の移行を取得した後、rake dbを実行します。 backup:read。

schema_infoは、Railsの古いバージョンのものです。 schema_migrationsは、ブロックの新しい子供です。 schema_infoテーブルは使用されなくなるため、削除できるはずです。この名前の変更に関連する問題を検索することをお勧めします。

rake db:schema:loadは、schema.rbからデータベース構造をロードします。このファイルは、データベース構造の現在の表現です。すべてのテーブルとインデックスの作成を必要とする空のスキーマ(データベース)がある場合に使用されます。すべての移行を実行する必要がなくなります。既存の本番データベースにデータが入っている場合、それを実行したくありません。他の人が言っているように、それは悪いだろう!

この投稿はしばらく前のものでしたが、偶然見つけたので、まだ回答がありません。グーグルで登場するように、ここに行きます。

rake db:schema:dumpを実行したとき(またはビルドスクリプトによってこれが行われたとき)、移行テーブルの定義をschema.rbに配置します。スクリプトの最後に、プロセスはテーブルを再度作成しようとしますが、明らかに既に存在します。 rake:schema:loadを実行する前にschema.rbから移行テーブルを削除するだけで、エラーメッセージは表示されません。

後で移行を実行するには、移行テーブルでバージョン番号を設定する必要があります。そのため、schema.rbがどのバージョンに関連しているのかを知るか、古い移行をすべて削除することが重要です(SCMに安全ですか?)

rake db:migrate RAILS_ENV=production

最初の作成にのみ db:schema:load タスクを使用し、増分変更を移行する必要があります。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top