Active laufen verschiedene Abfragen in der Produktion?

Question

Ich habe eine Klassenhierarchie sieht wie folgt aus:

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

Es gibt einen Controller, der Daten wie so holt:

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

In development, diese läuft die folgende Abfrage, gerade aus den Protokollen:

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

Doch sobald es in production Modus laufen gelassen, sogar mit der gleichen Datenbank und Daten, es ergibt sich folgende Abfrage:

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

Hat jemand wissen, warum dies geschieht, und ist es eine Möglichkeit, es zumindest zu erhalten, consistantly verhalten, wenn nicht gar das Problem beheben?

Answer 1

Es ist ein offenes Ticket für diesen Fehler hier: https: // rails.lighthouseapp.com/projects/8994/tickets/188-single-table-inheritance-bug-only-in-production-environment

Die Lösung wird am unteren Rand dieses Ticket aufgeführt: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2389-sti-changes-behavior-depending-on-environment

Zitat:

  

Sie müssen explizit Subklassen Namen in   die Elternklasse

     

Klasse ProjectFeedEvent

def self.subclasses
  [ProjectAddedEvent]
end  

     

Ende

Ein Teil der Grund, warum dieses Problem für eine Weile gewesen und hat nicht viel Aufmerksamkeit erhalten, ist, dass STI nicht allgemein notwendig, in Rails ist. Die meisten Mitwirkenden zu Rails haben beschlossen, sie in ihren eigenen Projekten nicht zu verwenden und daher keine Zeit in der Herstellung sicher gestellt, dass es gut unterstützt wird. Hier ist eine Klappentext, die kurz erklärt, warum Sie nicht verwenden sollten, und schlägt eine Alternative: http://www.matthewpaulmoore.com/ruby-on-rails-code-quality-checklist#sti

Meine persönlichen Erfahrungen STI in meinem Unternehmen mit war, dass zunächst sehr nützlich schien, sondern im Laufe der Zeit haben wir festgestellt, dass wir einfach nicht haben müssen genug, um die Komplexität zu rechtfertigen. Seitdem hat sich unser Projekt dramatisch gewachsen und wir haben es gar nicht übersehen.

Answer 2

Da in der Produktion alle Klassen werden sofort geladen. Wenn alle Klassen laden sie erkennt, dass ProjectDesignWall eine Unterklasse von Projekt ist somit alle von ihnen sammelt.