SCI magic when you don't want it

24 views
Skip to first unread message

Jamie Orchard-Hays

unread,
Feb 5, 2014, 2:19:41 PM2/5/14
to mongo...@googlegroups.com
Is there a way to prevent the _type key/value from being automagically added to a base class when you're *not* using SCI?

I have class Bom. class RemovedBom inherits from it but has its own collection.

Boms are getting _type, which I don't want.

Cheers,

Jamie

Chris Heald

unread,
Feb 5, 2014, 6:36:26 PM2/5/14
to mongo...@googlegroups.com
Mm. It doesn't look like it - inheritance seems to always create the _type key. That seems erroneous.

You should be able to add this monkeypatch to fix it: https://gist.github.com/cheald/8835643

I'll patch it, as well. I can't think of a reason why you'd want to add the _type key if the subclass has a different collection specified than its superclass.

-- Chris

Jamie Orchard-Hays

unread,
Feb 5, 2014, 6:46:55 PM2/5/14
to mongo...@googlegroups.com
Thanks, Chris. I'll try that. I agree, it's undesirable to add _type if you're not actually using SCI for an inherited model.

Cheers,

Jamie

--
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
---
You received this message because you are subscribed to the Google Groups "MongoMapper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongomapper...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Chris Heald

unread,
Feb 5, 2014, 6:47:43 PM2/5/14
to mongo...@googlegroups.com
https://github.com/mongomapper/mongomapper/commit/ca70c43e78fa5530dd7da6190eec2f7524f367c1 - if you just want to pull master, it's in there now. Travis is chewing on it, but specs pass locally.

Jon Kern

unread,
Mar 9, 2014, 8:14:46 PM3/9/14
to mongo...@googlegroups.com
Hi Jamie, 

A bit off topic… more about your model than about using MM…

On the surface, you seem to want inheritance, but not the mechanism that places _type into the base class, eh? 

That seems a tad confusing — but I likely do not have enough information on your domain model…

Maybe you can share your thinking on this?

It seems you have a BOM (bill of material, I presume?) class as the base/parent class. Maybe it points to a ProductType, and maybe it has a collection of parts.

And then you have a RemovedBom class — maybe adding who, when, for auditing, to the Bom base class? 

On the surface, this child class seems like it might be used to capture the “state” of a Bom instance?

Curious...

Jamie Orchard-Hays

unread,
Mar 9, 2014, 11:33:28 PM3/9/14
to mongo...@googlegroups.com
You're guesses are good:

Bom is Bill of Materials

RemovedBom is a removed one that we keep in a separate collection for our records. 

Since they are virtually identical, it makes sense to inherit Bom in RemovedBom, but I definitely do not want them stored in the same collection.

We need to keep track of all our customers' BOMs when they are removed.

I don't care if STI is default or not, but I want to turn it on or off when I want it. It is *too* opinionated to make me use STI just because I've inherited a model into another. 

Jamie

For more options, visit https://groups.google.com/d/optout.

Jon Kern

unread,
Mar 12, 2014, 8:06:46 PM3/12/14
to mongo...@googlegroups.com
Weird that you just don’t set a state to something like “removed.” But okay, I’ll assume you have good reasons (like there is a crapload of removed BOMs and you don’t want to scope every query to exclude removed items). 

A separate collection sounds easy, and sounds like there is no need to use inheritance at all.

Couldn’t you simply create a RemovedBOM from a BOM (or move BOM to RemovedBom)? Literally.

In other words, the state transition diagram of a BOM has a “removed” transition. Upon that transition firing, you don’t just set the state to “removed” but you yank it out of your collection and dump it into a different collection. Can you undo this “remove” transition? If so, just move it back ;-) Thankfully the document-as-json makes this easy, right?

Jamie Orchard-Hays

unread,
Mar 13, 2014, 11:01:03 AM3/13/14
to mongo...@googlegroups.com
Yes, I have good reasons not to keep the removed BOMs in the same collection as the current ones.

Here's the exact code for removing:

# Copies Bom to removed_boms and its Products to removed_products
# Then deletes Bom and Products if successful
# Does not copy Products of Boms with load_error, just deletes them
# Uses Mongo driver directly so we don't lose the file data (fs.files, fs.chunks)
def remove(remover = nil)
  removed_at = Time.now.utc
  mongofied = self.to_mongo.merge({:remover_id => remover.try(:id), :removed_at => removed_at})
  mongofied.delete("_type") # boms get marked with _type: "Bom" since RemovedBom inherits. Yargh
  if self.load_error?
    if RemovedBom.collection.save(mongofied)
      self.destroy_products
      self.collection.remove(:_id => self.id)
      true
    else #clean up
      RemovedBom.delete_all(:_id => self.id)
      false
    end
  else
    if RemovedBom.collection.save(mongofied) && 
       Product.where(:load_name => load_name).all.collect{|p| RemovedProduct.collection.save(p.to_mongo.merge({:removed_bom_id => self.id, :removed_at => removed_at}))}.all?
       self.destroy_products
       self.collection.remove(:_id => self.id)
      true
    else #clean up
      RemovedBom.delete_all(:_id => self.id)
      RemovedProduct.delete_all(:removed_bom_id => self.id)
      false
    end
  end
end
Reply all
Reply to author
Forward
0 new messages