5

Rails 3.2.2 と mongoid 2.4.6 を使用しています。コレクションを小さく保つために、「store_in」ステートメントを使用して、子オブジェクトを別のコレクションの基本クラスに格納しています。私のコードは次のようになります。

class BaseClass
  include Mongoid::Document
end

class ChildClass1 < BaseClass
  store_in :child_1
end  

class ChildClass2 < BaseClass
  store_in :child_2
end

オブジェクトがまたは他の子コレクションにランダムに格納されているようです。タイプ Child1 のオブジェクトがコレクション Child2 に格納されることがあります。ログに表示される驚くべきことは次のとおりです。

Started POST "/child_class_1" for 127.0.0.1 at 2012-05-22 10:22:51 -0400
Processing by ChildClass1Controller#create as HTML

MONGODB (0ms) myproject_development['child_2'].insert....

それはどこから来たのですか？これは、mongoid、rails、または mongodb のバグですか?

4

1 に答える 1

10

少し時間がかかりましたが、答えがわかりました。他の方の参考になればと思い投稿することにしました。

Mongoid は「単一テーブル継承」と呼ばれるものを実装しています。親クラスから子クラスを派生させるとすぐに、子は「type」属性を追加して親コレクションに格納されます。「store_in」を使用すると、ドキュメントを保存するコレクションを mongodb に明示的に伝えます。子クラスで store_in を定義すると、mongoid は指定されたコレクションにすべて (親を含む) を保存します。各子に専用の store_in 割り当てを使用すると、mongoid が台無しになると思います。ただし、その結果、ドキュメントは指定されたコレクションのいずれかにランダムに格納されます。

これは、共通機能の mixin としてモジュールを使用する Ruby で解決できます。これは、このドキュメントでかなり詳しく説明されています。

しかし、私は結局これをしないことにしました！私がこれを望んだ理由は、より良いパフォーマンスを得ることを望んで、私のコレクションを小さく保つためです. 一部の (10gen) 専門家と話をした後、すべての子要素に対して単一の親オブジェクト コレクションを使用する方が良いと思います。mongodb のパフォーマンスに影響はないはずですが、ソリューションはより柔軟になります。実際、これにより、mongodb のスキーマレス設計をより有効に活用できます。

したがって、コードは次のようになります。

class BaseClass
  include Mongoid::Document

  ... shared functionality

end

class ChildClass1 < BaseClass
  ...individual functionality...
end  

class ChildClass2 < BaseClass
  ...individual functionality...
end
于 2012-05-24T14:27:51.433 に答える