Вопрос по inheritance, ruby-on-rails, mongodb – Mongoid store_in дает случайные результаты

4

Я использую Rails 3.2.2 с mongoid 2.4.6. Чтобы мои коллекции были небольшими, я храню дочерние объекты в базовом классе в отдельных коллекциях, используя & quot; store_in & quot; заявление. Мой код выглядит так:

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, рельсах или mongodb?

Вы пробовали обновиться до последней версии Mongoid? Я полагаю, что это в настоящее время 2.4.10. theTRON

Ваш Ответ

1   ответ
9

но я понял ответ. Я решил опубликовать это, надеясь, что это поможет другим.

Mongoid реализует то, что называется «наследование одной таблицы». Как только вы извлекаете дочерний класс из родительского класса, дочерний класс будет сохранен в родительской коллекции с добавлением & quot; типа & quot; приписывать. Использование & quot; store_in & quot; сообщает mongodb, в какой коллекции хранятся документы. Определение store_in в дочернем классе заставляет mongoid хранить все (включая родительский) в данной коллекции. Я предполагаю использование выделенных назначений store_in для каждого дочернего беспорядка. Однако в результате документы хранятся случайным образом в любой из заданных коллекций.

Это может быть решено в Ruby, используя модуль как миксин для общей функциональности. Это очень хорошо описано вэтот документ.

BUT I decided not to do this after all! The reason why I wanted this is in order to keep my collections small, hoping to get better performance. After talking to some (10gen) experts I think the better approach is to use the single parent object collection for all child elements. There should be no impact on the performance of mongodb but the solution becomes much more flexible. In fact this makes much better use of the schemaless design in mongodb.

Так что код снова будет выглядеть так:

class BaseClass
  include Mongoid::Document

  ... shared functionality

end

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

class ChildClass2 < BaseClass
  ...individual functionality...
end
Error: User Rate Limit Exceeded

Похожие вопросы