3

クラス階層は次のようになります。

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

なぜこれが起こっているのか誰かが知っていますか?問題を完全に修正しない場合でも、少なくとも一貫して動作させる方法はありますか?

4

2 に答える 2

5

本番環境では、すべてのクラスが一度にロードされるためです。すべてのクラスがロードされると、ProjectDesignWall が Project のサブクラスであることが認識され、すべてのクラスが収集されます。

于 2009-04-01T06:35:50.473 に答える
2

このバグのオープン チケットがここにあります: 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

引用するには：

親クラスのサブクラスに明示的に名前を付ける必要があります

class ProjectFeedEvent < FeedEvent

def self.subclasses
  [ProjectAddedEvent]
end

終わり

この問題がしばらく発生し、あまり注目されていない理由の 1 つは、Rails では STI が一般的に必要ないことです。Rails への貢献者のほとんどは、Rails を自分のプロジェクトで使用しないことを決定したため、Rails が十分にサポートされていることを確認することに時間を費やしていません。これを使用すべきではない理由を簡単に説明し、代替案を提案する宣伝文句を次に示します。

私の会社で STI を使用した私自身の個人的な経験では、最初は非常に便利に思えましたが、時間が経つにつれて、複雑さを保証するのに十分である必要はないと判断しました。それ以来、私たちのプロジェクトは劇的に成長し、私たちはそれを見逃すことはありません.

于 2009-04-02T07:16:50.010 に答える