ActiveRecord запускает различные запросы в процессе производства?

Question

У меня есть иерархия классов выглядит следующим образом:

class Post < ActiveRecord::Base; end 
class Project < Post; end 
class ProjectDesignWall < Project; end 

Там есть контроллер, который извлекает данные, как так:

@projects = Project.find(:all, :include => [:project_image_photos,:user]) 

В development это работает следующий запрос, прямо из бревен:

SELECT * FROM `posts` WHERE ((`posts`.`type` = 'Project')) ORDER BY originally_created_at DESC 

Однако, как только он запускается в режиме production, даже с той же базой данных и данными, это приводит к Следующий запрос:

SELECT * FROM `posts` WHERE ((`posts`.`type` = 'Project' OR `posts`.`type` = 'ProjectDesignWall')) ORDER BY originally_created_at DESC 

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

Answer 1

Существует открытый билет на эту ошибку здесь: https://rails.lighthouseapp.com/projects/8994/tickets/188-single-table-inheritance-bug-only-in-production-environment

Решение перечисленных в нижней части этого билета: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2389-sti-changes-behavior-depending-on-environment

Цитирую:

Вы должны явно назвать подклассы в родительский класс

класс ProjectFeedEvent < FeedEvent

def self.subclasses 
    [ProjectAddedEvent] 
end 

конец

Одной из причин этой проблемы существует уже некоторое время и не получил много внимания, что ИППП обычно не нужно в Rails. Большинство участников Rails решили не использовать его в своих проектах и ​​поэтому не тратьте время на то, чтобы убедиться, что он хорошо поддерживается. Вот краткое изложение, в котором кратко объясняется, почему вы не должны его использовать, и предлагает альтернативу: http://www.matthewpaulmoore.com/ruby-on-rails-code-quality-checklist#sti

Мои личные переживания, связанные с использованием STI в моей компании, были, поначалу, очень полезными, но со временем мы определили, что мы просто не нуждался в этом достаточно, чтобы гарантировать сложность. С тех пор наш проект резко вырос, и мы его совсем не пропустили.

Answer 2

Потому что в производстве все ваши классы загружаются сразу. Когда все классы загружаются, он понимает, что ProjectDesignWall является подклассом Project, таким образом, собирает все из них.