1

Sorry if the question is awkwardly phrased -- still a Mongo/Mongoid/Rails newbie here.

What I'm trying to ask:

In my development, I've been changing around the design of my Models as I go, adding some fields here, removing some fields there (one of the great things about MongoDB/Mongoid is that you can do this very quickly and easily!)

Everything is working, but in browsing through the development database, I've got some "detritus" -- documents with the old fields (and data) that aren't being used. It's no big deal other than to my garbage-collective sensibilities. I could, in theory, drop the DB and start from scratch, but that's messy.

Is there a utility / gem / etc. that will, essentially, look at the current document design and drop any fields in the live DB that don't match up to the data model?

I know this can be done manually, and I know about the mongoid migrations gems that are out there -- those are both good and, ultimately, more thorough solutions (which I'll look at).

For now, though, I'm wondering if there's a simple "quick shot" type of utility to simply sync up the DB and drop any fields that aren't explicitly specified in my models.

Thanks!

nlh
  • 1,055
  • 1
  • 10
  • 15
  • 1
    It's a feature of mongodb to not need to keep your schema in old models up to date. – Jesse Wolgamott Dec 03 '12 at 19:19
  • I know - but when I make changes, the documents using the "old" data model still have "old" fields and I'd like to be able to clear those out without re-creating the whole database. – nlh Dec 04 '12 at 05:09

1 Answers1

0

I don't know of any tools that do this for you. It's not a common ask because most people see this flexibility as a useful feature.

For your development database, you should probably clear it out and start over.

In production you have a couple choices:

  • Write your code to be robust against fields being missing and the database documents not matching your mongoid model. In other words, be prepared for the two to get out of sync.

  • Get in the habit of migrating your data every time you change the model. It's a bit of hassle and not strictly necessary if you follow the first, but if the untidiness bothers you, this is a fine idea. See Managing mongoid migrations for strategies.

Community
  • 1
  • 1
Leopd
  • 41,333
  • 31
  • 129
  • 167