I changed a table field using a migration. It worked. I reinstalled the app and ecto.create. It can't find the field

My app had a table field that I replaced “altered” using a migration file.

I updated all my code and my app recognized the field as expected.

I created a fresh install (removed _build and deps directories) , set a different database in config/dev and went through the setup process.

When I run the app from the browser it asks me to run migrations (If I look in priv/repo/migrations there are no migration files)

Error that says that the updated field I replaced can not be found. I attached an image of the error

ERROR 42703 (undefined_column) column “url” does not exist

Error in image:

There is nothing in the error that tells me what I am expected to do in Elixir Phoenix.

Hey @wktdev

(If I look in priv/repo/migrations there are no migration files)

How can there be no migration files? You said in your first sentence that you used a migration file, where did it go?

I had migration files before I wiped them along with the _build and deps folders.
I assumed they shouldn’t be needed if my schema is set. My goal is to be able to install an app that works on another server.

The migration files are what configure the database. If you are trying to use the app against a fresh database, you need those files.

Alternatively you can mix ecto.dump from a database that is set up, and that will give you a structure.sql file with the complete structure. Then mix ecto.load on your fresh database. You would want to check that structure.sql file into the project.

EDIT: Note that the structure.sql approach only works as an initialization step, you can’t use that to modify a database. If your code changes and you need to update the database you will need the migrations to do so.


Okay thank you. I assumed that ecto.create would see my schema and use that to create the database.

No ecto.create only makes the database, it does not put anything in it implicitly. Do see my edit in my the post above regarding updating databases. I would strongly recommend keeping migrations around.

1 Like