[sodapopcan]

As I said, I would use it if it existed. But I have never experienced anything close to fear when writing migrations, that sounds insanely hyperbolic. The most I've experience is very mild pain.

There's also the thing that schemas are not 1-to-1 with tables in Ecto (I realize it's possible in ORMs too, but not as ergonomic). Sure, you don't have to do this, and many don't, but it's very useful.

[boxed]

I don't know about fear. The Django migrations are a bit stupid in some ways so introduces some fear.

It's more about the speed of development. I sometimes make many migrations per day. It's just so fast I don't really think about changing models at all.

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