7 responses to “Migrations with Mongo (and MongoMapper)”

• 

  Sohan February 28th, 2010 at 03:03

  Your post has been linked at http://www.DrinkRails.com!

• 

  Stephen Eley March 1st, 2010 at 13:33

  As a result, the first time I tried to visit a page with my user, I got a sweet NoMethodError, because apparently nil doesn’t implement strftime.

  …Or your partner could have added a :default => value on any new keys he created in the model, which in Does the Right Thing in MongoMapper and takes the place of “nil” for any existing records.

  This is a neat idea, but I don’t see much use for a whole new layer of process in a typical MongoMapper app deployment. MM can handle the uncomplicated cases very elegantly with defaults and callbacks. For the complicated cases where data does need to be transformed, you haven’t really removed the overhead of having to remember to run a Rake task. That’s not hard for a typical small project, and if your development is incremental and additive, changes that warrant it shouldn’t be that common. If I had a big team or big production app farm where I’d have to worry about more than a couple of installations, I’d probably roll the transformation script into an initializer in the app. That way I could be sure it was done before the code that needed it.

  Rollbacks are sort of a silly idea in MongoMapper. Again, a data transformation that breaks old code is just so rare. They were a silly idea in ActiveRecord migrations too — I’ve never seen a production snafu where a migration rollback was part of the recovery. So much coding time goes into them, and yet it’s so much more reliable just to back up the database as part of a deployment and then restore from it if things explode.

• 

  terry March 1st, 2010 at 16:34

  I think as soon as you decide to, say, break name into first_name and last_name, default starts to fall short. You want to write a query where last_name != ‘foo’, but :default doesn’t fix that (I don’t think).

  The only rake task is a single one, just to run mongrations. It’s just given as part of most deployments today anyway that you’ll need to migrate your database, so it lets developers add something in that will get run automagically – no notes, “hey run this after you push the code.”

  I really like rollbacks when writing migrations. I’ll usually re-run the same migration several times.

• 

  Stephen Eley March 3rd, 2010 at 01:06

  My point about defaults was just that they’ll help you avoid the dreaded NoMethodError. They’re obviously no substitute for having actual data.

  As it happens, I have run into the name-splitting issue in the recent past, thanks to having to integrate with a braindead membership database. I handled it by overriding the read accessors to figure it out from the Name field when the more specific ones weren’t filled in. I even tried to handle middle initials (our audience is academics, so this matters):

  # An intelligent guess at first name where none exists
  def first_name
  attributes[:first_name] || name.split[0]
  end

  # An intelligent guess at middle initial where none exists
  def middle_name
  attributes[:middle_name] || (((a = name.split($;,3)).length == 3) ? a[1] : nil)
  end

  # An intelligent guess at last name where none exists
  def last_name
  attributes[:last_name] || name.split($;,3)[-1]
  end

  This isn’t perfect, but it’s a decent 80% solution, and the user can fix any mistakes themselves in their profile. Querying’s not really a problem; you just do a regex query into the complete Name field, which will have all the components.

  It’s just given as part of most deployments today anyway that you’ll need to migrate your database,

  But some of us started using MongoDB in part to get away from that. >8->

• 

  Stephen Eley March 3rd, 2010 at 01:25

  Oh, and hey — for what it’s worth, it really wasn’t my intention to be a hater here. I’m playing Devil’s Advocate to some extent, but I don’t actually think this is a bad idea. We have different approaches, but that’s not a Bad Thing. And the implementation looks decent. (You do need tests, though.) >8-P

  I can particularly see how this could be a handy helper for someone just transitioning into MongoMapper from more ActiveRecordish approaches, or even for an existing Rails project that’s starting to move some models into Mongo but not all at once.

  So please don’t read my comments above as trying to say “This is stupid and you should stop.” If I meant that, that would be stupid. And I should stop.

• 

  terry March 3rd, 2010 at 07:08

  Not at all. If I can’t defend the way of doing it, then there’s not really a point to having it, am I right?

• 

  terry March 3rd, 2010 at 07:14

  So I think I might be in the crazy part of the population that likes migrations, almost to a fault, but I have read a lot of posts with that sentiment.

  When I read your first comment I was originally thinking of a middle_initial counter argument, but I decided that you’d probably answer with a method that tries to figure it out.

  I’m not sure what I think of that implementation though. I’ve done it a lot in the past, where the accessor defaults the value which lets the db clean itself up, but I’m not sure I want the default values to live in the model. Then again, maybe that’s where they’re supposed to live.

  I think if you can write queries without having to worry about the defaults, then your solution is just as appropriate as a mig(mong)ration.

  Feel free to change my mind.