PG non esiste una relazione di errore indefinibile per gli utenti

Ho visto questa domanda prima, ma solo per rspec. Non ho ancora creato il test perché è troppo avanzato per me ma un giorno presto lo farò! : P

Ricevo questo errore quando provo a registrarmi / accedere alla mia app. Ho usato devise per creare utenti e anche omniauth2 per accedere con google .

questo è l'errore

ActiveRecord::StatementInvalid at /users/auth/google_oauth2/callback
PG::UndefinedTable: ERROR:  relation "users" does not exist
LINE 5:              WHERE a.attrelid = '"users"'::regclass
                                        ^
:             SELECT a.attname, format_type(a.atttypid, a.atttypmod),
                     pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod
              FROM pg_attribute a LEFT JOIN pg_attrdef d
                ON a.attrelid = d.adrelid AND a.attnum = d.adnum
             WHERE a.attrelid = '"users"'::regclass
               AND a.attnum > 0 AND NOT a.attisdropped
             ORDER BY a.attnum

Ho provato rake db:migrate, ma è già stato creato: nella tabella dello schema esistono gli utenti. Qualcuno ha ricevuto questo errore prima?

database.yml

config = / opt / local / lib / postgresql84 / bin / pg_config

development:
  adapter: postgresql
  encoding: unicode
  database: tt_intraweb_development
  pool: 5
  username: my_username
  password:

test:
  adapter: postgresql
  encoding: unicode
  database: tt_intraweb_test
  pool: 5
  username: my_username
  password:

production:
  adapter: postgresql
  encoding: unicode
  database: tt_intraweb_production
  pool: 5
  username: my_username
  password:

In un primo momento, scollegherai tutte le connessioni dal database. Per impostazione predefinita, utilizzi l' ambiente di sviluppo . Quindi prova a ripristinare il database con quanto segue:

rake db:reset

L'attività rake db: reset eliminerà il database e lo configurerà di nuovo. Questo è funzionalmente equivalente a rake db: drop db: setup.

Non è la stessa cosa che eseguire tutte le migrazioni. Utilizzerà solo il contenuto del file schema.rb corrente. Se una migrazione non può essere ripristinata, rake db: reset potrebbe non aiutarti. Per ulteriori informazioni sul dumping dello schema, vedere la sezione Dumping dello schema e te. Rails Docs

Se il trucco non aiuta, rilascia il database, quindi ricrealo di nuovo, migra i dati e, se hai seed, semina il database:

rake db:drop db:create db:migrate db:seed

o in breve (dal 3.2):

rake db:migrate:reset db:seed

Poiché db:migrate:resetimplica eliminare, creare e migrare il db. Poiché l'ambiente predefinito per rakeè lo sviluppo , nel caso in cui si visualizzi l'eccezione nei test delle specifiche, è necessario ricreare il database per l' ambiente di test come segue:

RAILS_ENV=test rake db:drop db:create db:migrate

o semplicemente caricando lo schema migrato:

RAILS_ENV=test rake db:drop db:create db:schema:load

Nella maggior parte dei casi, il database di test viene seminato durante le procedure di test, quindi db:seednon è necessario passare l'azione dell'attività. Altrimenti, devi preparare il database (questo è deprecato in Rails 4 ):

rake db:test:prepare

e poi (se effettivamente richiesto):

RAILS_ENV=test rake db:seed

Nelle versioni più recenti di Rails l'errore ActiveRecord :: NoEnvironmentInSchemaError potrebbe essere aumentato, quindi anteponi le attività con un ambiente di database set task: db: environment: set :

RAILS_ENV=test rake db:environment:set db:drop db:create db:migrate

Ho riscontrato questo errore e, sulla base della mia ricerca, ho scoperto che uno dei motivi per la relazione di errore indefinibile PG non esiste l' errore è:

Questo errore è un errore di migrazione. Potresti aver creato un nuovo modello con alcuni attributi del database. Dopo aver creato il modello, devi migrare gli attributi allo schema della tua app rails.

Se stai usando una macchina locale, per lo sviluppo, puoi usare command

rake db:migrate

Se stai usando heroku

heroku run rake db:migrate

Il database di prova non è pronto per rspec.

Preparare il database di test per rspec per correggere questo errore

RAILS_ENV=test rake test:prepare

Rilascerà, creerà e aggiungerà migrazioni al database di prova

Nel caso in cui l'attività rake venga interrotta con un messaggio come "PG :: Error: ERROR: database" [your_db_test] "è accessibile da altri utenti, esegui questo

RAILS_ENV=test rake db:migrate

Ho avuto un errore simile. La radice del mio errore era che avevo un riferimento a un modello Rails nel mio file factories.rb. Quindi ha causato un problema di errore di caricamento. La soluzione era racchiudere il riferimento in un blocco o in {}modo che ne ritardi l'esecuzione.

Ecco il codice BROKEN:

FactoryGirl.define do
  factory :user do
    guid User.new.send(:new_token)
  end
end

Ed era in errore perché Usernon era definito durante il caricamento di factories.rb. Ho racchiuso la User.newchiamata in un blocco e ha risolto il problema:

Codice fisso:

FactoryGirl.define do
  factory :user do
    guid { User.new.send(:new_token) }
  end
end

Nota: probabilmente non è consigliabile chiamare il tuo modello in questo modo, ma è stata una soluzione per DRY il mio codice.

Ho ricevuto anche questo errore durante l'esecuzione di rspec:

 Failure/Error: it { expect(subject.priority_list).to eq [nil] * 9 }
 ActiveRecord::StatementInvalid:
   PG::UndefinedTable: ERROR:  relation "priorities" does not exist
   LINE 5:              WHERE a.attrelid = '"priorities"'::regclass
 ...

È stato risolto per me dopo aver corso

rake db:test:prepare
rake db:test:load

Ciò è spesso causato da un bug in ActiveAdmin. Ecco come aggirare il bug:

Se stai utilizzando ActiveAdmin, a seconda di quale tabella PG dice non esiste, commenta il contenuto di quel file rb di ActiveAdmin.

Ad esempio, in questo caso PGError: ERROR: relation "users" does not exist, commentare l'intero contenuto di app/admin/users.rb, quindi rimuovere il commento dopo aver eseguito le migrazioni.

Quel problema per me è stato causato dai binari Factory Girl. Consiglierei a coloro che lo usano di rinominare la cartella specs / factories in specs / temp e tentare

RAILS_ENV = your_environment bundle exec rake db: migrate --trace

Se passa, hai appena scoperto cosa lo stava causando. Una rapida ricerca nel repository github di Factory Girl Rails mi ha aiutato a identificare il problema.

Le fabbriche stavano fallendo perché stavo cercando di istanziare un modello che non esisteva durante l'esecuzione! Esempio di codice di seguito:

FactoryGirl.define do
  factory :billing_product, class: 'Billing::Product' do
    name            Faker::Cat.name
    product_type    'fuel'
    active          true
    payment_options [Billing::PaymentOption.new(term: 1, payment_term: 1)]
  end
end

L'incapsulamento dell'array in un blocco (l'aggiunta di {}) ha risolto il problema. Tieni presente che payment_options può richiedere più di un'opzione di pagamento nell'esempio ...

payment_options {[Billing::PaymentOption.new(term: 1, payment_term: 1)]}

Fare riferimento alla parte relativa agli attributi dinamici della documentazione di Factory Girl Rails per maggiori informazioni.

Non dimenticare di rinominare nuovamente la cartella delle fabbriche!

Stavo affrontando lo stesso problema e poi ho scoperto la seguente soluzione.

Assicurati di aver inserito tutte le seguenti credenziali nel file database.yml e che siano corrette:

development:
 adapter: postgresql
 encoding: unicode
 database: my_database
 host: localhost
 port: 5432
 pool: 5
 username: postgres
 password: xyz

test:
 adapter: postgresql
 encoding: unicode
 database: my_test_database
 host: localhost
 port: 5432
 pool: 5
 username: postgres
 password: xyz 

Ho avuto questo problema dopo aver eliminato la tabella degli utenti. le soluzioni stavano cambiando

change_table(:users)

per

create_table(:users)

::Migration[5.0]mancava nelle migrazioni. invece di generare un errore di sintassi , genera

PG :: UndefinedTable: ERRORE: i ruoli di relazione non esistono

dopo aver perso ore ho finalmente capito che mancava la migrazione ::Migration[5.0].

Migrazione errata:

class CreateRoles < ActiveRecord # <---- Pay attention
  def change
    create_table :roles do |t|
      t.string :name
      t.integer :code, limit: 2
      t.boolean :is_active, default: true

      t.timestamps
    end
  end
end

Migrazione corretta e corretta

class CreateRoles < ActiveRecord::Migration[5.0]
  def change
    create_table :roles do |t|
      t.string :name
      t.integer :code, limit: 2
      t.boolean :is_active, default: true

      t.timestamps
    end
  end
end

Questo potrebbe essere un bug con i binari e potrebbe aiutare qualcuno, invece di lottare e chiedersi.

Ho ricevuto un errore simile durante il tentativo di eseguire i test utilizzando rspec.

Ho seguito i passi di Малъ Скрылевъ ma sono finito comunque breve. Il passaggio finale che dovevo fare era caricare il mio schema nel mio database di test utilizzando:

RAILS_ENV=test rake db:schema:load

Dopo di che il problema è andato via e sono potuto passare al bug successivo. Spero che questo ti dia qualche idea.

Rimuovi la cartella Admin ed esegui di nuovo rake.

(So ​​che questo è vecchio, ma per i futuri googler)

Stai usando devise? So che nello specifico omniauthableè un problema, ma forse anche altri. Non deve essere per forza devise. Generalmente la soluzione è commentare il modello, la classe, qualunque cosa incriminata e annullare il commento delle sezioni richieste dagli errori.

Per me, quello che stava succedendo è devisestato leggere il Usermodello per vedere cosa hai come argomenti devise(il metodo di classe cioè devise :database_authenticatable, :registerable #etc)

Ma leggerà l'intero file e se questo non è un nuovo progetto potrebbe essere bloccato da altri metodi di classe che si affidano ad altre cose (nel mio caso era la friendly_idgemma, e quindi unalias_method

La risposta è stata commentare il Usermodello tranne che per le deviselinee * e rake db:schema:loaddovrebbe funzionare bene.

• altrimenti ho ricevuto questo errore:

  ArgumentError: mappatura omniauth_callbacks su una risorsa che non è omniautabile Si prega di aggiungere devise :omniauthableal Usermodello

Se ricevi questo errore durante la migrazione, assicurati che il nome del tuo modello sia plurale

per esempio.

add_column :images, :url, :string

La causa più probabile è che il tuo rake utilizzi un ambiente diverso da database.yml rispetto al tuo server web.

Ho avuto questo problema e si è scoperto essere causato da Grape API . Ho notato nella traccia dello stack che il file delle rotte veniva letto durante la migrazione.

In route.rb è montata l'API Grape

mount API::Base => '/'

E nell'API c'erano riferimenti al modello mancante. Quindi, grazie a questa risposta lo metto in un blocco che rileva se viene eseguito dal server o durante la migrazione.

unless ( File.basename($0) == "rake" && ARGV.include?("db:migrate") )
    mount API::Base => '/'
end

E ha funzionato.

Ho type_zonesriscontrato il seguente errore e ho cercato in tutto il codice dell'applicazione perché non sono riuscito a trovarlo. Ho anche guardato il db ed è stato aggiornato.

Si scopre che era un file sotto i proiettori /test/fixtures/type_zones.ymlche stava causando il problema.

ERROR["test_should_get_new", UsersControllerTest, 0.47265757399145514]
test_should_get_new#UsersControllerTest (0.47s)
ActiveRecord::StatementInvalid:  ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR:  relation "type_zones" does not exist
    LINE 1: DELETE FROM "type_zones"
                        ^
    : DELETE FROM "type_zones"

Per chiunque abbia ancora questo problema, nel mio caso, è stata la mia fabbrica in FactoryGirl a causare questo errore.

Stavo cercando di aggiungere un riferimento tramite ".new" o ".create".

Nel mio caso, ho dovuto commentare 2 ActiveAdmin file. Ecco i miei passi:

1. Errore iniziale / stacktrace (nota che stiamo usando Solrsu questo progetto): ⇒ rkdbm java version "1.7.0_25" Java(TM) SE Runtime Environment (build 1.7.0_25-b15) Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode) => Solr is already running rake aborted! PG::UndefinedTable: ERROR: relation "discussions" does not exist LINE 5: WHERE a.attrelid = '"discussions"'::regclass ^ : SELECT a.attname, format_type(a.atttypid, a.atttypmod), pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum WHERE a.attrelid = '"discussions"'::regclass AND a.attnum > 0 AND NOT a.attisdropped ORDER BY a.attnum /Users/matthewcampbell/Sites/code/stack-builders/AchieveX/app/admin/users.rb:25:in block in <top (required)>' /Users/matthewcampbell/Sites/code/stack-builders/AchieveX/app/admin/users.rb:1:in' /Users/matthewcampbell/Sites/code/stack-builders/AchieveX/config/routes.rb:3:in block in <top (required)>' /Users/matthewcampbell/Sites/code/stack-builders/AchieveX/config/routes.rb:1:in' /Users/matthewcampbell/Sites/code/stack-builders/AchieveX/config/environment.rb:5:in `' Tasks: TOP => db:migrate => environment (See full trace by running task with --trace)

Ho commentato il app/admin/discussions.rbfile in base alla risposta di Arcolye sopra e ho provato a migrare nuovamente il mio database.

Stesso errore.

Ho esaminato lo stacktrace un po 'più da vicino e ho notato che in effetti app/admin/users.rb:25stava lanciando l'eccezione e, abbastanza sicuro, quel file ha una dipendenza dalla mia discussionstabella (tramite l'esecuzione Discussion.all).

Infine, commentare i contenuti di users.rbmi ha permesso di migrare finalmente con successo il mio database.

FYI: c'è una discussione qui in ActiveAdmincirca se quella gemma dovrebbe caricare il database quando richiesto.

Quindi avere lo stesso problema proprio ora. Ricorda di avere un solo modello in ogni migrazione. Questo mi ha risolto.

Ho trovato la risposta qui.

Stavo rilevando l'errore:

ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR:  relation "users" does not exist
LINE 8:                WHERE a.attrelid = '"users"'::regclass

Si è rivelata una soluzione super facile. Avevo copiato i file da una versione precedente del progetto e mi ero dimenticato di annidarli all'interno di una cartella "migrate". Quando l'ho fatto, ho risolto il problema.

di solito può accadere quando si utilizza un tipo sbagliato di associazione tra i modelli, si verifica la distruzione delle dipendenze e ha_many associazioni, ad esempio:

modo sbagliato che può causare questo problema:

articolo.rb

 has_many :subcategories, through: :categories, dependent: :destroy

subcategory.rb

has_and_belongs_to_many :articles

giusta direzione:

articolo.rb

 has_many :subcategories, through: :categories, dependent: :destroy

subcategory.rb

declare association with categories here not articles (belongs_to / has_many_and_belongs_to)