I’m working through Programming Phoenix >= 1.4 and was surprised to see that mix ecto.migration doesn’t actually create migrations automatically. Coming from a Django background this seems like a major additional step every time we make changes to the database schema (which happens very often for a startup!)
Is there a reason for this, or is it something that just hasn’t been implemented yet?
Hey. not sure what you mean and I dont remember how it works in Django but the migration file is generated with a command like
mix ecto.gen.migration add_users
That would give you an empty migration file. But if you run a command like
mix phx.gen.live Users User users name:string email:string
It would create a full set of CRUD files including a migration that creates a users table with a name and email column.
There are also several other commands.
In frameworks like Symfony/Doctrine you can enter a command to edit a schema. For instance you wil add a new field. The command asks for the name and type of the field, and then update the schema file and generates a migration for the new field.
That would be very cool to have this in ecto but I guess it is a lot of work.
I guess the reason for ecto to not do that is much more that in ecto schemas don’t need to map 1:1 to tables. You can have a single schema for a single table maping to all fields, but you can also have a schema mapping to more fields than a single table or to a subset of fields of a table. You can have many schemas mapping to a table and you can have a single schema be used with multiple tables.
Effectively when you add a field to a schema in ecto there’s no way to know if you also need another column in the db or not.
Even when they do, there are database use cases for ecto schemas which don’t require migrations at all. Building an Elixir app which accesses a preexisting database or database otherwise built/managed elsewhere wouldn’t have migrations to update.
I think of you’re working with an ORM, there is an expectation of a tight ORM to database server coupling. Ecto, not being an ORM, but rather a data mapper with ORM like capabilities the effort was likely put elsewhere. I could see a case for schema managed migrations, but am not surprised that they didn’t exist it of the gate nor seen as priority to get done up to this point.
While that is true I’m pretty sure you can do the same with any ORM since you can override the table name, and opt-out generating the migration.
In Django, you edit the Python file where your models are defined, make whatever changes you want (adding/removing fields, indexes, tables, constraints, etc), and then run makemigrations which inspects the changes, compares them to the existing schema, and generates the entire migration for you (which is a python file). You then apply the migration as a separate step migrate which updates the database. You can also edit the migration manually if you need to but that’s rare.
This is very useful especially when a project is young and you’re changing the schema many times per day.
Sounds pretty interesting, however I doubt it is that useful. Let’s say you have a table with data in it and you want to change the type of a column, I doubt the migrations will be capable to do that automatically. Usually if we talk about many changes to database structure, you just write seeds, migrations and drop the database each time a new version is deployed.
Moreover, like people mentioned above, there are a lot of times when your schema might differ from the table structure, so you lose this flexibility if you want automatic migrations.
© Copyright Elixir Forum | Terms | Privacy & Cookies
