Rails и Heroku PGError: столбец не существует

Question

Эта страница, которую я разрабатывал для своего приложения, работала нормально локально (с использованием sqllite3), но когда я отправляю ее в Heroku, которая использует PostgreSQL, я получаю эту ошибку:

NeighborhoodsController # (ActionView :: Template :: Error) "PGError: ERROR: column \" isupforconsideration \ "не существует \ nLINE 1: ... \" photos \ "WHERE (соседство = 52 AND isUpForCon ... \ п

Из этой строки кода:

@photos = Photo.where(["neighborhood = ? AND isUpForConsideration = ?", @neighborhood.id, 1])

isUpForConsideration является частью колонки Photo. Все мои миграции обновлены, и когда я возвращаю базу данных локально, isUpForConsideration все еще там, и приложение все еще работает локально.

Я также пробовал:

@photos = @neighborhood.photos(:conditions => {:isUpForConsideration => 1})

и

@photos = @neighborhood.photos.where(["isUpForConsideration = 1"])

Что дает мне эту ошибку:

NeighborhoodsController # (ActionView :: Template :: Error) "PGError: ERROR: column \" isupforconsideration \ "не существует \ nLINE 1: ... tos \" WHERE (\ "photos \". Соседство = 52) AND (isUpForCon ... \ n

Есть идеи, что я могу делать не так?

Answer 1

Ваша проблема в том, что имена таблиц и столбцов чувствительны к регистру в PostgreSQL . Обычно это скрыто путем автоматического преобразования их в строчные буквы при выполнении запросов (отсюда и причина того, почему вы видите сообщение об ошибке, сообщающее «isupforconsideration»), но если вам удалось избежать этого преобразования при создании (двойными кавычками в имени, как это делает Rails вы, когда вы создадите таблицу), вы увидите эту странность. Вам нужно заключить «isUpForConsideration» в двойные кавычки при использовании его в предложении WHERE, чтобы это исправить.

, например

@photos = @neighborhood.photos.where(["\"isUpForConsideration\" = 1"])

Answer 2

Другой способ получить эту ошибку, изменив миграцию и перенеся изменения в Heroku, не перестраивая таблицу.

Предостережение: Вы потеряете данные и, возможно, ссылки, поэтому я собираюсь объяснить, плохая идея , если вы не уверены, что никакие ссылки не будут потеряны. Rails предоставляет способы изменения таблиц с помощью миграций - создавайте новые миграции для изменения таблиц, обычно не изменяйте сами миграции после их создания.

Сказав это, вы можете запускать heroku run rake db:rollback, пока та таблица, которую вы изменили, не всплывет, а затем запустить heroku run rake db:migrate, чтобы вернуть ее с вашими изменениями.

Кроме того, вы можете использовать гем taps для резервного копирования и восстановления данных. Сносите таблицы базы данных, разбирайте их так, как вам нужно, а затем поднимайте столы назад с помощью нажатий. Я делаю это довольно часто на этапе прототипирования. Я бы никогда этого не сделал с живым приложением.