PG undefinedtable Error Relacja użytkowników nie istnieje

Widziałem to pytanie wcześniej, ale tylko dla rspec. Nie stworzyłem jeszcze testu, ponieważ jest dla mnie zbyt zaawansowany, ale wkrótce to zrobię! : P

Ten błąd pojawia się, gdy próbuję się zarejestrować / zalogować do mojej aplikacji. Użyłem devise do stworzenia użytkownika, a także omniauth2 do logowania się z Google .

to jest błąd

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

Próbowałem rake db:migrate, ale już jest utworzony: w tabeli schematu istnieją użytkownicy. Czy ktoś miał wcześniej ten błąd?

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:

Najpierw należy odłączyć wszystkie połączenia z bazy danych. Domyślnie używasz środowiska programistycznego . Następnie spróbuj zresetować bazę danych, wykonując następujące czynności:

rake db:reset

Zadanie rake db: reset usunie bazę danych i skonfiguruje ją ponownie. Jest to funkcjonalnie równoważne z rake db: drop db: setup.

To nie to samo, co uruchamianie wszystkich migracji. Wykorzysta tylko zawartość bieżącego pliku schema.rb. Jeśli migracji nie można cofnąć, rake db: reset może nie pomóc. Aby dowiedzieć się więcej o zrzucaniu schematu, zobacz sekcję Schema Dumping and You. Rails Docs

Jeśli sztuczka nie pomoże, upuść bazę danych, a następnie utwórz ją ponownie, przeprowadź migrację danych, a jeśli masz seedy, zasiej bazę danych:

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

lub w skrócie (od 3.2):

rake db:migrate:reset db:seed

Ponieważ db:migrate:resetimplikuje upuszczenie, utwórz i przeprowadź migrację bazy danych. Ponieważ domyślnym środowiskiem dla środowiska testowegorake jest programowanie , w przypadku wystąpienia wyjątku w testach specyfikacji należy ponownie utworzyć bazę danych dla środowiska testowego w następujący sposób:

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

lub po prostu ładując zmigrowany schemat:

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

W większości przypadków testowa baza danych jest zasiewana podczas procedur testowych, więc db:seednie jest wymagane wykonanie zadania. W przeciwnym razie powinieneś przygotować bazę danych (jest to przestarzałe w Railsach 4 ):

rake db:test:prepare

a następnie (jeśli jest to rzeczywiście wymagane):

RAILS_ENV=test rake db:seed

W nowszych wersjach Railsów może pojawić się błąd ActiveRecord :: NoEnvironmentInSchemaError , więc po prostu uzupełnij zadania o zadanie zestawu środowiska bazy danych: db: environment: set :

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

Napotkałem ten błąd i po moich badaniach odkryłem, że jedną z przyczyn braku niezdefiniowanej relacji błędów użytkowników PG jest:

Ten błąd jest błędem migracji. Być może utworzyłeś nowy model z niektórymi atrybutami bazy danych. Po utworzeniu modelu musisz przenieść atrybuty do schematu aplikacji railsowej.

Jeśli używasz komputera lokalnego do programowania, możesz użyć polecenia

rake db:migrate

Jeśli używasz heroku

heroku run rake db:migrate

Twoja testowa baza danych nie jest gotowa na rspec.

Przygotuj swoją testową bazę danych dla rspec, aby naprawić ten błąd

RAILS_ENV=test rake test:prepare

Porzuci, utworzy i doda migracje do twojej testowej bazy danych

W przypadku przerwania zadania rake z komunikatem typu „PG :: Error: ERROR: baza danych„ [your_db_test] ”jest używana przez innych użytkowników, wykonaj to

RAILS_ENV=test rake db:migrate

Miałem podobny błąd. Przyczyną mojego błędu było to, że miałem odniesienie do modelu Rails w moim pliku factories.rb. Więc spowodowało to problem z błędem ładowania. Rozwiązaniem było zawinięcie odwołania w blok lub {}opóźnienie jego uruchomienia.

Oto kod BROKEN:

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

I to było błąd, ponieważ Usernie zostało zdefiniowane podczas ładowania pliku factory.rb . Zawinąłem User.newpołączenie w blok i rozwiązałem problem:

Naprawiono kod:

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

Uwaga: prawdopodobnie nie jest to najlepsza praktyka, aby wywoływać swój model w ten sposób, ale było to rozwiązanie do WYSUSZANIA mojego kodu.

Otrzymałem również ten błąd podczas uruchamiania 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
 ...

Zostało to rozwiązane za mnie po bieganiu

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

Jest to często spowodowane błędem w programie ActiveAdmin. Oto jak obejść błąd:

Jeśli używasz ActiveAdmin, niezależnie od tego, która tabela PG mówi, że nie istnieje, zakomentuj zawartość tego pliku ActiveAdmin rb.

Na przykład w tym przypadku PGError: ERROR: relation "users" does not existwykomentuj całą zawartość app/admin/users.rb, a następnie usuń komentarz po zakończeniu migracji.

Ten problem był dla mnie spowodowany przez szyny Factory Girl. Poleciłbym tym, którzy go używają, zmienić nazwę folderu specyfikacji / fabryk na specyfikacje / temp i spróbować

RAILS_ENV = pakiet twoje_środowisko exec rake db: migrate --trace

Jeśli minie, to właśnie znalazłeś, co go powoduje. Szybkie przejrzenie repozytorium klejnotów Factory Girl Rails na githubie pomogło mi zidentyfikować problem.

Fabryki zawodziły, ponieważ próbowałem utworzyć egzemplarz modelu, który nie istniał po uruchomieniu! Przykładowy kod poniżej:

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

Hermetyzacja tablicy w bloku (dodanie {}) rozwiązała problem. Zwróć uwagę, że payment_options może przyjąć więcej niż jedną opcję płatności w przykładzie ...

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

Więcej informacji można znaleźć w części Dynamic Attributes w dokumentacji Factory Girl Rails .

Nie zapomnij z powrotem zmienić nazwy folderu fabryk!

Miałem ten sam problem, a potem odkryłem następujące rozwiązanie.

Upewnij się, że wprowadziłeś wszystkie poniższe poświadczenia w pliku database.yml i są one poprawne:

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 

Miałem ten problem po usunięciu tabeli użytkowników. rozwiązania się zmieniały

change_table(:users)

do

create_table(:users)

::Migration[5.0]brakowało podczas migracji. zamiast wyrzucać błąd składniowy, który wyrzuca

PG :: UndefinedTable: ERROR: role w relacji nie istnieją

po zmarnowaniu godzin w końcu zorientowałem się, że brakuje migracji ::Migration[5.0].

Błędna migracja:

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

Naprawiona i poprawna migracja

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

Może to być błąd związany z railsami i może komuś pomóc, zamiast walczyć i zastanawiać się.

Otrzymałem podobny błąd podczas próby uruchomienia testów przy użyciu rspec.

Podążyłem śladami Малъ Скрылев, ale i tak skończyłem krótko. Ostatnim krokiem, który musiałem zrobić, było załadowanie schematu do mojej testowej bazy danych za pomocą:

RAILS_ENV=test rake db:schema:load

Po tym problem zniknął i mogłem przejść do następnego błędu. Mam nadzieję, że da ci to trochę wglądu.

Usuń folder Admin i ponownie uruchom rake.

(Wiem, że to jest stare, ale dla przyszłych pracowników Google)

Czy używasz devise? Wiem, że konkretnie omniauthablejest problem, ale może też inne. Nie musi tak być devise. Generalnie rozwiązaniem jest wykomentowanie obraźliwego modelu, klasy, czegokolwiek i usunięcie komentarzy do wszystkich sekcji, o które proszą błędy.

Dla mnie to, co się działo, deviseto czytanie Usermodelu, aby zobaczyć, do czego masz argumenty devise(metoda klasy tj. devise :database_authenticatable, :registerable #etc)

Ale odczyta cały plik i jeśli nie jest to nowy projekt, może zostać wyzwolony przez inne metody klas opierające się na innych rzeczach (w moim przypadku był to friendly_idklejnot, a następniealias_method

Odpowiedzią było skomentowanie Usermodelu z wyjątkiem deviselinii * i rake db:schema:loadpowinno działać dobrze.

• inaczej otrzymałem ten błąd:

  ArgumentError: Mapowanie omniauth_callbacks w zasobie, którego nie można omijać Proszę dodać devise :omniauthabledo Usermodelu

Jeśli pojawia się ten błąd podczas migracji, upewnij się, że nazwa modelu jest liczbą mnogą

na przykład.

add_column :images, :url, :string

Najbardziej prawdopodobną przyczyną jest to, że Twoja rake używa innego środowiska niż database.yml niż Twój serwer WWW.

Miałem ten problem i okazało się, że jest to spowodowane przez Grape API . Zauważyłem w śladzie stosu, że plik tras był odczytywany podczas migracji.

W route.rb montowany jest interfejs Grape API

mount API::Base => '/'

A w API były odniesienia do brakującego modelu. Tak więc dzięki tej odpowiedzi umieściłem go w bloku, który wykrywa, czy jest uruchamiany przez serwer, czy podczas migracji.

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

I zadziałało.

Wystąpił następujący błąd i przeszukałem cały kod aplikacji, ponieważ type_zonesnie mogłem go znaleźć. Obejrzałem też bazę danych i została zaktualizowana.

Okazuje się, że /test/fixtures/type_zones.ymlproblem powodował plik pod urządzeniami .

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"

Dla każdego, kto nadal ma ten problem, w moim przypadku to moja fabryka w FactoryGirl wywoływała ten błąd.

Próbowałem dodać odniesienie przez „.new” lub „.create”.

W moim przypadku musiałem wykomentować 2 ActiveAdmin pliki. Oto moje kroki:

1. Początkowy błąd / śledzenie stosu (uwaga, używamy Solrw tym projekcie): ⇒ 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)

Skomentowałem app/admin/discussions.rbplik zgodnie z powyższą odpowiedzią Arcolye i ponownie spróbowałem zmigrować moją bazę danych.

Ten sam błąd.

Przyjrzałem się nieco dokładniej stosowi śledzenia i zauważyłem, że w rzeczywistości app/admin/users.rb:25rzuca wyjątek - i na pewno ten plik ma zależność od mojej discussionstabeli (poprzez wykonywanie Discussion.all).

Wreszcie, wykomentowanie zawartości witryny users.rbumożliwiło mi pomyślną migrację bazy danych.

FYI: jest tutaj dyskusja na ActiveAdmintemat tego, czy ten klejnot powinien ładować bazę danych, gdy jest to wymagane.

Więc mam teraz ten sam problem. Pamiętaj, aby mieć tylko jeden model w każdej migracji. To mnie rozwiązało.

Tutaj znalazłem odpowiedź.

Łapałem błąd:

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

Okazało się, że to super łatwa naprawa. Skopiowałem pliki ze starszej wersji projektu i zapomniałem zagnieździć je w folderze „migracja”. Kiedy to zrobiłem, rozwiązało to problem.

zwykle może się to zdarzyć, gdy używasz niewłaściwego typu powiązań między modelami, sprawdzasz, czy nie ma zniszczonych zależności i masz_wiele asocjacji, na przykład:

zły sposób, który może spowodować ten problem:

article.rb

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

subcategory.rb

has_and_belongs_to_many :articles

właściwa droga:

article.rb

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

subcategory.rb

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

Zapomnienie o pliku migracji w zatwierdzeniu może spowodować ten problem. Wciśnięty na heroku np. rails db:migrateOczywiście nie zadziała. Upewnij się, że plik migracji definiujący niezdefiniowaną tabelę został zatwierdzony.