(this is similar to Generate migrations from Ecto.Schemas or use those Ecto.Schemas to create tables in database but i still don’t have an application… so the proposed solution
ecto.dump doesn’t really apply)
I’m just starting out an elixir application using the whole mix package (phx, ecto) for the first time.
The initial migration seems extremely backwards to me. But i’m not that versed on ORMs either. I can see why I wouldn’t want migrations after the DB exists to screw up tables and such. But for the initial one, I honestly cannot see any advantage.
What is bugging me most is, i will spend probably several days authoring a bunch of Schema in my repo. Then, i will have to repeat line by line all the tables/fields into my initial migration file. Not to mention that at this time, until I have anything in production, i want to collapse all my “migrations” into a initial one anyone.
Does this make sense? anyone have any work around to save the initial work on this? any workflow that is more practical not covered on the official guide?
or, does everyone ignores all that and uses
phx.gen.schema right away?
…it was kinda confusing as the phx guides makes me go trhu the ecto guides first.
I’m a bit low on time so I can’t reply to your whole post but this part at least is pretty normal:
At least until my project is on some other developer’s computer, it’s perfectly fine to just edit your initial migrations and
it’s perfectly fine to just edit your initial migrations and mix ecto.reset.
makes sense, but i would rather to “redo my initial-migration-from-schemas and mix ecto.reset”
If you’re at that point, the workflow I generally use is to write out the
mix phx.gen commands I run, and then I just edit those as I want to tweak stuff and just keep deleting the lib / priv directories until things are the way I want. This also helps solve any html boilerplate (if applicable).
i see. so the usual process is to ignore
echo.migration initial and never manually editing Schemas/Migrations.Create_xxx, and going straight to
edit: …and then manually tweaking the fields not present on the html/api endpoints? sigh…
@gcb I haven’t read the books you’re referring to in a long time, so I don’t know what you mean by
ecto.migration initial. You asked about alternative work flows and I’m saying I jump straight in to
phx.gen. This minimizes the tweaking.