Hacker News Reader

Comment by boxed | Hacker News Reader

Last time I looked Ecto didn't have automatic migrations I think. Does it now? I can't imagine working without this feature after many years of Django...

View on HN

It takes the more Rails-like approach where you run a mix command to generate a migration (and that potentially writes out an elixir module with the Ecto schema, eg, when defining a whole new table) rather than Django's approach of updating your `models.py` and then having `manage.py makemigrations` introspect the DB and generate the migration code from that. I do slightly prefer Django's approach, but it's an easy adjustment to make.

On the other side, `mix ecto.migrate` essentially works the same as `manage.py migrate` for bringing your database in line with the set of migrations in your code.

I don't know why this is always talked about as if it's some killer feature. You still have to review the migration its generated, don't you? Don't get me wrong, it's a nice feature that I would use if were available, but certainly not even on a list of dealbreakers for me when evaluating a framework.

Ash framework [0] does have this feature, though.

[0] https://ash-hq.org/

The people who talk about it consider it to be a killer feature. I certainly do. There's considerably less ass pain and fear involved in Django migrations.

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.

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.

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.

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.

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.

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.

I haven't looked at an auto generated migration in years. So no.

No and it is not on anyone roadmap. So far we have not had anyone that found a way to make it work well.

You just need to cover the easy 80%, and nicely tell you to go to the documentation for the other cases.

Django migrations have been doing this for a long time...

Ash has automatic migrations. They are great when they work. When they don't...

When they don't you just write them yourself. All we do is generate migration files to provide a good starting point. Its a convenience tool.

Reply on news.ycombinator.com