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.

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.

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->

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.

…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.