When you subclass, MongoMapper assumes you're putting two types of objects in the same collection and automatically adds a check for the :_type key to all the queries. See https://github.com/jnunemaker/mongomapper/blob/master/lib/mongo_mapper/plugins/sci.rb
You can see the extra criteria added by inspecting the query that MongoMapper uses to find documents:
Article.query.to_hash
=> {:transformer=>#<Proc:...>}
DeletedArticle.query.to_hash
=> {:transformer=>#<Proc:...>, :_type=>{"$in"=>["DeletedArticle"]}}
The easiest fix right now is to make sure that all your deleted articles have their :_type set to "DeletedArticle", or define all the articles keys in a module that you include and then you don't have to use inheritance like so:
module Article
extend ActiveSupport::Concern
included do
key :title
key :author_id
timestamps!
end
# etc...see MongoMapper's source for many good examples
end
class ActiveArticle
include MongoMapper::Document
include Article
end
class DeletedArticle
include MongoMapper::Document
include Article
end
More broadly, and this is a question for the MongoMapper community, how should MongoMapper behave when an inherited model defines a new collection name? Should it shut off SCI at that point?
Brian
> --
> You received this message because you are subscribed to the Google
> Groups "MongoMapper" group.
> For more options, visit this group at
> http://groups.google.com/group/mongomapper?hl=en?hl=en
On Thursday, March 8, 2012 at 4:16 PM, Brian Hempel wrote:
More broadly, and this is a question for the MongoMapper community, how should MongoMapper behave when an inherited model defines a new collection name? Should it shut off SCI at that point?
jon
blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA
Rodrigo said the following on 3/8/12 3:22 PM:
See the following code, the "all" method is delegated to the "query" method, the "query" method returns a plucky query that has extra behavior added.
https://github.com/jnunemaker/mongomapper/blob/master/lib/mongo_mapper/plugins/querying/plucky_methods.rb#L9-11
https://github.com/jnunemaker/mongomapper/blob/master/lib/mongo_mapper/plugins/querying.rb#L63-70
https://github.com/jnunemaker/mongomapper/blob/master/lib/mongo_mapper/plugins/persistence.rb#L42-50
If using SCI: https://github.com/jnunemaker/mongomapper/blob/master/lib/mongo_mapper/plugins/sci.rb#L23-27
https://github.com/jnunemaker/plucky/blob/master/lib/plucky/query.rb#L73-75
https://github.com/jnunemaker/plucky/blob/master/lib/plucky/query.rb#L54-57
https://github.com/mongodb/mongo-ruby-driver/blob/master/lib/mongo/collection.rb#L207-260
Let me know if you have any questions on the above.
Brian
Jamie
In this case, it seems to me more for a technical reason that you sought
inheritance. After all, a "state" that could reflect DraftArticle,
UnderReviewArticle, PublishedArticle, DeletedArticle would not, I hope,
engender a new subclass?
And, in a single-inheritance language, you can really get into trouble
rather quickly doing inheritance.
(Of course, when it comes to more technical classes that are servicing
UIs, network IO, or other non-business domain classes, I relax my
constraints.)
Probably a fault of cutting my teeth on O-O in the (!)halcyon days of
C++ multiple inheritance being thoroughly abused by folks.
I have learned that inheritance can unnecessarily complicate a
developer's life when it isn't the best approach for the situation at
hand...
Of course, as the saying goes, YMMV.
jon
blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA
Rodrigo said the following on 3/9/12 3:30 PM: