0

これは、作成されたプロジェクトでアセットパイプラインを有効にすることと同じだと--skip-sprockets思います-私は間違っている可能性があります。

テストのために実行しようとしていますが、config / application.rbにrake assets:precompileすでに追加require 'sprockets/railtie'しているので、少なくともタスクは検出されますが、次のように表示されます。

no such table: app_configs

更新：このエラーは、AppConfigというアプリケーションのモデルから発生していることがわかりました。そのため、その部分を調べています。このレーキタスクを実行しているときにのみ発生する理由がわかりません...

更新：この特定のrakeタスクは、開発環境にいるにもかかわらず、実稼働環境にいることを前提としているようです。他のレーキタスクにはこの問題はないようです...？これは、実際に実行されているタスクが次のとおりであることを示しています。/home/.../bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUP=assets

したがって、間違ったデータベース（おそらく存在すらしていないデータベース）を検索しているため、テーブルが見つからないことは理にかなっています。しかし、それが本番環境にあることを（誤って）どのように判断しているのでしょうか？

4

1 に答える 1

1

それが判明したとして：

私はアセットパイプラインをほぼ正しくセットアップしました。あなたがしなければならないのはrake rails:update、プロジェクトファイルがすべて現在のRails gem（3.1.x）と互換性があるように更新されていることを確認するために実行することだけです。ファイルを上書きするときに警告が表示され、変更を表示してファイルを自分で編集できます（残念ながらマージオプションはありません）。configこれらの変更には、（ディレクトリ内の）アセットパイプラインに固有のいくつかの構成ディレクティブが含まれます。

私が遭遇した1つの特別な問題は、この投稿で対処されています：タスク'assets：precompile'を構築する方法 -（私は必要rails/allではなかったので、必要なスプロケットを追加する必要がありました）

これをすべて行った後、私は本番環境の問題に遭遇しました。アセット：プリコンパイルタスクは、本番環境を意図的に使用して、本番用のアセットを作成します。開発環境を使用する場合は、environments/development.rb通常ダイジェストURLを含まない構成に従ってアセットをコンパイルします。つまり、これは意図的なものです。問題は、本番環境を初期化するときに、開発環境に存在しないデータベースにアクセスしようとしていることです。これを回避する方法（テスト目的）は、これをconfig/application.rbファイルに追加することです。

config.assets.initialize_on_precompile = false

これにより、アプリと出来上がりを初期化できなくなり、アセットの事前コンパイル中に初期化エラーが発生しなくなります:) ただし、何らかの理由で非本番環境ですべてのアセットを事前コンパイルする場合を除いて、これをfalseに設定したままにする理由はありません。 （Herokuのように）アプリをデプロイするときに、Capistranoやその他のデプロイメントツールが本番環境でそれらをコンパイルできるようにするのではなく。initialize_on_precompileを使用すると、アセットテンプレートでモデルやその他のアプリケーションリソースを実際に使用できます。これは便利な機能です。

別の役立つ投稿： Rails3からRails3.1へのアップグレード

于 2012-10-26T16:35:27.390 に答える