die Datenbankkonfiguration gibt keinen Adapter an

als ich versuchte, ein Befehlszeilenskript auszuführen (sagen wir 'my_script' hier), ist der gleiche Fehler aufgetreten. Die Gründe waren:

1. Dort gibt es nur Produktionsumgebung.
2. Ich habe es versäumt, Rails_ENV für die Befehlszeile festzulegen.

Das Folgende ist also die Lösung in meinem Fall:

$ Rails_ENV = my_script der Produktion

Ich hatte gerade dieses Problem und wurde durch einen Tippfehler in meiner configration.yml verursacht.

Ich hatte ursprünglich folgendes:

production:
  adapter:mysql

Wenn ich das haben wollte:

production:
  adapter: mysql

Der kleine Abstand zwischen adapter: und mysql macht den Unterschied.

Eine andere mögliche Ursache:

In Rails 3.2.x hat establish_connection ein Standardargument aus der Umgebung:

Von connection_specification.rb :

def self.establish_connection(spec = ENV["DATABASE_URL"])
  resolver = ConnectionSpecification::Resolver.new spec, configurations
  spec = resolver.spec

Die Funktionsweise von ConnectionSpecification::Resolver hängt davon ab, dass ENV['DATABASE_URL'] eine nil angibt, falls nicht festgelegt. (Normalerweise wäre es so etwas wie 'postgres://...').

Wenn Sie also DATABASE_URLENV['DATABASE_URL'] == '' falsch konfiguriert haben, erhalten Sie database configuration does not specify adapter.

Ich hatte diesen Fehler, als ich versehentlich den Rails-Server mit gestartet habe

Sudo Rails s-e "Produktion" -p 80

und ich hätte Rails mit starten sollen

Sudo Rails s -e "Produktion" -p 80

Für mich löste dieser Befehl das Problem.

rake db: migriere Rails_ENV = production

Ich habe eine andere Sache gefunden, die dieses Problem verursachen kann: "Einmischen" eines anderen YAML-Knotens mit & und *.

Ich habe ursprünglich so etwas wie das Folgende gemacht, um lokale, per Entwicklung entwickelte, von Git ignorierte Konfigurationsdateien zu ermöglichen:

http://blog.lathi.net/articles/2006/03/02/config-database-yml-goodness-for-teams

Nach einigem Debugging stellte ich jedoch fest, dass establish_connection aus irgendeinem Grund nur mit den eingemischten Schlüssel-Wert-Paaren und nicht mit den Hauptpaaren aufgerufen wurde. Das heißt adapter, Host und database wurden nicht übergeben. Ich habe keine Ahnung, warum und das hat für mich funktioniert.

Anstatt in einen anderen YAML-Knoten zu mischen, füge ich nun die gesamten development- und test-Hashes in die lokale Konfigurationsdatei ein, und establish_connection wird wieder korrekt aufgerufen.

Ich habe den gleichen Fehler erhalten, indem ich den folgenden Befehl eingegeben habe:

db:migrate Rails_ENV=product

Hätte sein sollen:

db:migrate Rails_ENV=production

Ich habe ein paar Hinweise gefunden, dass dies mit älteren Bibliotheken (ActiveRecord) oder Gem-Versionen zusammenhängt. Zum Beispiel: Probleme mit Fixtures, auch wenn der Rest der App in Ordnung ist (nach einem Upgrade) oder dieses Trac-Ticket , das "Gems davon abhält, einen Adapter von einem alten Active Record-Gem zu benötigen". Beide sind zwar alt, aber es lohnt sich möglicherweise, sicherzustellen, dass Ihre Edelsteine ​​auf dem neuesten Stand sind (wenn möglich).

Verwenden Sie zufällig den nativen Rails MySQL-Adapter? Dies ist jetzt unter Rails veraltet, aber es ist denkbar, dass es immer noch humpelt.

Ich habe auch sehr schnell einen Blick auf connection_specification.rb geworfen, woher dieser Fehler kommt. Meine beste Vermutung ist, dass eine erneute Verbindung fehlschlägt ... aber warum (da es offensichtlich in Ordnung war, als Sie die App zum ersten Mal gestartet haben) ? Tun Sie etwas wildes, wie den Aufruf von ActiveRecord::Base.establish_connection in Ihrem Anwendungscontroller (oder anderswo)? 

Oder vielleicht so etwas wie: Script Runner wird in der Nacht von cron aus aufgerufen, wenn die Verbindung abbricht. Leider wird der Läufer mit einem falschen Rails_ENV aufgerufen. Daher wird die falsche Zeilengruppe aus database.yml gelesen, und diese Zeilengruppe enthält einen ungültigen adapter:?

Denken Sie daran, dass Rails_ENV = Staging in Ihrer database.yml nach einer Staging-Spezifikation sucht, genauso wie das Festlegen von Rails_ENV = production in der Datei database.yml nach einer Produktionsspezifikation sucht. 

Stellen Sie, wie unten gezeigt, Datenbankkonfigurationen bereit, z. B. für jede Rails-Umgebung, die Sie als Ziel verwenden 

bundle exec cap staging deploy

production:
  adapter: mysql2
  encoding: utf8
  database: Rails
  username: Rails
  password: pass
  Host: 127.0.0.1
  port: 3306
  pool: 5
  timeout: 5000

staging:
  adapter: mysql2
  encoding: utf8
  database: Rails
  username: Rails
  password: pass
  Host: 127.0.0.1
  port: 3306
  pool: 5
  timeout: 5000

Wenn Sie diesen Fehler während der Bereitstellung mit Capistrano erhalten. Stellen Sie sicher, dass Sie den richtigen Rails_ENV über eingestellt haben 

set :Rails_env, 'production'

Zum Beispiel habe ich die Rails-Umgebung nicht explizit für die Capistrano-Bereitstellungskonfiguration festgelegt. Und so verwendete Capistrano "Staging" als Rails_ENV, was zu dem oben genannten Fehler führte. Wenn Sie wie oben in der Datei staging.rb auf Produktion setzen, wurde das Problem behoben. 

Ich habe dieses Problem aufgrund des Problems mit der Unterstützung mehrerer Datenbanken festgestellt. In meinem app/model-Ordner befindet sich eine Datei, die eine redundante Datenbankverbindung definiert: 

class CacheCleanerActiveRecord < ActiveRecord::Base
  establish_connection "cache_cleaner_#{Rails.env}"
  self.abstract_class = true
end

diese Datenbank wird jedoch nicht in meiner database.yml gefunden (weil sie überhaupt nicht verwendet wird). 

die Lösung ist einfach zu beenden: Entfernen Sie diese Datei und alles ist in Ordnung! 

Wir hatten dieses Problem mit einer unserer älteren Apps. Jemand hatte eine Boutique mit dem Namen "Umgebung" erstellt, die, selbst wenn RAIL_ENV auf Produktion eingestellt war, nach einer Datenbankkonfiguration mit dem Namen legacy_<RAIL_ENV> suchte. Daher musste ich eine Datenbankumgebung mit dem Namen legacy_production erstellen, damit diese App funktioniert.

Wenn Sie die App einer anderen Person pflegen, würde ich nach einer Kopie des database.yml dieser App suchen, die funktioniert, vielleicht hat sie eine seltsam benannte Konfiguration. Sie können in Ihrer Codebase nach establish_connection suchen, um festzustellen, ob eine merkwürdige Variante definiert wird.

Denken Sie daran, den C-basierten Ruby-Edelstein für MySQL zu verwenden. Der Ruby-basierte ist für die Produktion instabil.

Installieren Sie den Edelstein

gem install mysql

Denken Sie daran, libmySQL.dll in das Ruby-Bin-Verzeichnis zu kopieren.

Möglicherweise haben Sie einen Fehler wie:

Rails_ENV= test

Ein Leerzeichen nach dem Gleichheitszeichen ist nicht zulässig. Ändern Sie es in:

Rails_ENV=test

Ich hatte diesen Fehler mit einem anderen Problem; Ich hatte zweimal "Entwicklung" angegeben und "Test" überhaupt nicht.

Es gibt viele schlechte Tutorials im Internet, die yaml-Dateien so zeigen:

development:
encoding: utf
database: dbname
...etc

Bei YAML-Dateien wird die Groß- und Kleinschreibung beachtet und für den inneren Inhalt jedes angegebenen Attributs vom Typ db sind ZWEI SPALEN erforderlich. So wie:

development:
  encoding: utf
  database: dbname
  ...etc

UPDATE: Ich habe diesen Fehlernoch einmalheute. Mein VPS-Server hatte Rails 3.2.8 installiert, als meine App Rails 3.2.6 ausführte.

Überprüfen Sie auf jeden Fall Ihre Gemfile-Datei und Ihre database.yml-Datei (natürlich). Das Problem hier ist eindeutig angegeben - Rails kommuniziert nicht spezifisch mit Ihrer Datenbank aufgrund eines Adapters (aka gem)

Sie müssen die Umgebung angeben, wenn Sie den Server oder den Befehl ausführen, da Ihre database.yml -Datei möglicherweise nur einen Produktionsadapter hat, während Sie einfach rake db: run ausführen: migrate nimmt beispielsweise Umgebungsvariable als Entwicklung an. 

Dies passiert mir, schließlich habe ich festgestellt, dass Rails_ENV die Groß-/Kleinschreibung berücksichtigt. In meiner Umgebung habe ich Rails_ENV=DEVELOPMENT eingestellt, was falsch ist. Der Wert von Rails_ENV muss Kleinbuchstaben sein.

$ Rails_ENV=DEVELOPMENT Rails server webrick
=> Booting WEBrick
=> Rails 4.2.5 application starting in DEVELOPMENT on http://localhost:3000
=> Run `Rails server -h` for more startup options
=> Ctrl-C to shutdown server
config.eager_load is set to nil. Please update your config/environments/*.rb files accordingly:

  * development - set it to false
  * test - set it to false (unless you use a tool that preloads your test environment)
  * production - set it to true

Exiting
/home/fangxing/.rvm/gems/Ruby-2.3.0/gems/activerecord-4.2.5/lib/active_record/connection_adapters/connection_specification.rb:248:in `resolve_symbol_c
onnection': 'DEVELOPMENT' database is not configured. Available: ["default", "development", "test", "production"] (ActiveRecord::AdapterNotSpecified)
        from /home/fangxing/.rvm/gems/Ruby-2.3.0/gems/activerecord-4.2.5/lib/active_record/connection_adapters/connection_specification.rb:211:in `res
olve_connection'



$ Rails_ENV=development Rails server webrick
RubyDep: WARNING: Your Ruby is outdated/buggy. (To disable warnings, set Ruby_DEP_GEM_SILENCE_WARNINGS=1)
RubyDep: WARNING: Your Ruby is: 2.3.0 (buggy). Recommendation: install 2.3.1.
=> Booting WEBrick
=> Rails 4.2.5 application starting in development on http://localhost:3000
=> Run `Rails server -h` for more startup options
=> Ctrl-C to shutdown server
[2016-07-20 16:41:09] INFO  WEBrick 1.3.1
[2016-07-20 16:41:09] INFO  Ruby 2.3.0 (2015-12-25) [x86_64-linux]
[2016-07-20 16:41:09] INFO  WEBrick::HTTPServer#start: pid=19881 port=3000

rake assets:precompile:all anrufen

Der Vollständigkeit halber habe ich gerade diesen Fehler erhalten, weil ich nativ ein parametrisiertes Rails-Runner-Skript erstellt habe, das eine E-Mail-Adresse verwendet und die Befehlszeilenoption -e benannt hat - was natürlich der Rails-Runner für die Umgebung ist. Es wurde also versucht, eine Umgebungskonfiguration zu finden, die mit der E-Mail-Adresse übereinstimmt!

Glücklicherweise gab es kurz vor dem im Titel erwähnten ActiveRecord-Fehler eine Fehlermeldung, die mir half, das eigentliche Problem zu unterscheiden:

You did not specify how you would like Rails to report deprecation notices for your [email protected] environment, please set config.active_support.deprecation to :log, :notify or :stderr at config/environments/[email protected]

Dies ist wahrscheinlich nicht das wahrscheinlichste Problem, das diesen Fehler verursacht, aber hier ist es nur für den Fall.

Mein Problem war, dass ich die Datenbankeinstellungen in einer Hash unter Verwendung von Symbolen als Schlüssel erstellte und sie dann mit #to_yaml in database.yaml serialisierte. ActiveRecord erwartet, dass die Umgebungsnamen Strings und nicht Symbols sind, sodass die Datenbankeinstellungen beim Lesen der generierten Datei nicht übernommen wurden. Ich habe es mit Hilfe von Stringschlüsseln im Hash behoben.

Rails -e "production" ist in Ordnung

nur Rails -e production gibt einen Fehler zurück

database configuration does not specify adapter (ActiveRecord::AdapterNotSpecified)

Bei Rails4 wurde die Zeile fetch(:default_env).merge!(Rails_env: 'production') in production.rb kommentiert und set :Rails_env, :production hinzugefügt.