[DangitBobby]

The fear isn't when writing migrations, it's when executing them in production. And please don't lecture me on how you should always be confident that your migrations work as expected before they go out.

It's okay if it doesn't solve a problem you have.

[sodapopcan]

Dangit, Bobby, please don't assume I'm going to lecture you ;)

But I'm very curious how this solves that problem. I've only ever had problems with migrations when misusing them to do data migrations. And of course when renaming and deleting columns... does it somehow create a multi-step deploy plan in these scenarios!?? If it did that then I'd change my tune. I can do reading on my own, though.

> It's okay if it doesn't solve a problem you have.

Once again, I'm not, repeat NOT, saying it's a bad feature. I even said I'd use it sometimes if it were available. I'm saying it's unfortunate when I hear people writing off an entire framework because it doesn't have this.

[thraxil]

Executing them in production by running `mix ecto.migrate` is essentially equivalent to running `manage.py migrate`. That part of the two approaches is really the same.

[sodapopcan]

Oh, ya, if DangitBobby is thinking there are no auto-mated migrations in production then we're talking about two different things. I just meant the ability to infer migrations from models.