Calling manager code from a migration script is a tricky situation. My concern revolves around the fact that these migration scripts are point-in-time, but the server code is always latest. The migrations are a path from old to the current code and rely on that path to remain constant, so calling out to current code in the middle is potentially going to break that incremental data integrity.

The situation here is cleaner than most since this method appears to be largely intended for migrations (compared to something the server would itself use such as create_repo). But it's also slightly dangerous in that respect as well.

Admittedly, the concerns I have with this approach are a bit far-fetched, I realize that. In theory, migrations that run after this will assume the model that you're instituting in this change to move to type_id : count.

If that format changes again, presumably this method will be updated with the new format (based on the method name). But that means that any migrations that ran after 0004 will assume the model at the time of 0004 but instead get the current model.

All that said, I'm not saying this is huge a problem here. Like I said, realistically the situation I describe is a stretch. But I wanted to at least explain why migrations that call into server code raise a flag for me since they stand to break the point-in-time behavior a migration is supposed to exhibit.