Ошибка при кэшировании классов с (именованными) областями

Question

Это запутанный пример, так что терпите меня:

У меня есть скрипт, который я обычно использую во время разработки, который уничтожит мои таблицы моих тестовых и тестовых баз данных, перенастроит их, а затем повторно заполнит их.Из-за моего использования триггеров в нескольких местах мне пришлось использовать rake db: migrate RAILS_ENV = test, чтобы правильно перенести мою тестовую базу данных.

Все было хорошо, пока я не включил config.cache_classes = true вмоя тестовая среда.Затем, когда миграция рейка выполнялась в пустой базе данных, я получал сообщение об отсутствии таблицы.Запустив это с --trace, я обнаружил, что он взрывается на одном из моих объектов, когда он объявляет базовую область видимости:

scope :find_by_route_and_date, lambda { |route_id, date|
    {
      :conditions=>{:route_id=>route_id, :schedule_date=>date}
    }
  }

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

Я схожу с ума?Кто-нибудь еще видел это?Если мне нужно стереть свою базу данных, нужно ли отключить кэширование, затем выполнить миграцию, а затем снова включить ее?

Rails 3.2, ruby ​​1.9.2, рейк 0.9.2.2

ОБНОВЛЕНО:

В соответствии с запросом, здесь трассировка стека: https://gist.github.com/1705064

Order.rb: 179 - это место, где определена моя первая область и куда она дуетдо того, что я перечислил выше.

Answer 1

Это интересно.Мое прочтение трассировки стека состоит в том, что rails пытается помочь вам понять, будет ли создавать эту область (т. Е. Создавать метод с тем же именем) проблему, перезаписывая какой-либо существующий метод.

Это приводитактивная запись вниз respond_to, где он считает, что имя вашей области видимости / метода очень похоже на динамический искатель.Затем он идет дальше: как выглядят как динамические искатели, существуют ли все названные атрибуты?Здесь он пытается проверить, какие столбцы есть в несуществующей таблице, и все взрывается.

Вы можете (я думаю) сделать одну из нескольких вещей:

• перед областью действияопределите метод класса с тем же именем, что и область действия, чтобы закорачивать вызов response_to (фу)
• изменить имя области действия
• переопределить valid_scope_name

Я до сих пор не уверен, почему вы не можете настроить тестовую базу данных из файла схемы, если необходимо установить дампер схемы на :sql, чтобы вещи, которые активная запись не поддерживает изначально, были сохранены.

Answer 2

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

Лучше всего всегда использовать более низкоуровневые методы манипулирования данными, которые будутработать независимо от состояния вашего каталога app/models.Хороший пакет миграции может построить из первоначального состояния до самой последней версии, не зацикливаясь на отсутствующих файлах или методах.Вот почему важно быть автономным.

Вы, вероятно, можете переписать эту область как более буквальную вещь, которую можно запустить с execute.

Если вы используете триггерыи возникли проблемы со средой test, поскольку дампер схемы не записывает их должным образом, вместо этого используйте формат :sql для своей схемы.Это более буквальная копия, и на нее не должны влиять ограничения формата Ruby-ized.