ActiveRecord выполняет разные запросы в производственном процессе? - PullRequest
3 голосов
/ 01 апреля 2009

У меня иерархия классов выглядит так:

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

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

Ответы [ 2 ]

5 голосов
/ 01 апреля 2009

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

2 голосов
/ 02 апреля 2009

Здесь есть открытый билет на эту ошибку: 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

def self.subclasses
  [ProjectAddedEvent]
end  

конец

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

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

...