How to bundle ecto migrations in a library?

I’ve got a library at work I’m looking to open-source. This library depends on ecto and migrations to create a table for itself. Do I have to do anything special to package the migrations so a normal mix ecto.migrate would run them? Is there an example of this somewhere I could see?

I want my library to just have a table inside of the user’s already existing database. Maybe that’s a bad idea, and I should just have it use it’s own database?

You can take a look at how Oban handles migrations. On a general note you wouldn’t bundle migration scripts, but your library would include apis for users to call in their own migration scripts.

1 Like

Cool, thanks, I’ll check it out.

It seems like making this an extra manual thing users would have to do would make it more error prone and easy to miss.

Not really, you include it front and center in your docs and tell them: “create a migration and run exactly this function inside the migration for the library to work”.

Can’t be missed or nothing is going to work for your library’s users.

I disagree. Your library is not in control of the users database, your users are and need to be. You can provide the “what needs to change”, but your users need to be able to control when those changes happen and at which cadance. E.g. they might be at V2 of your libraries db schema, while V5 is latest. Users might want to move to V5 directly or they might have lots of data and want to move one version at a time. There might be other changes in their db schema related to changes in your library. And in the end to me the most important part of migrations is that I can look into one folder and see all the changes applied to my database.

3 Likes

I think you meant cadence here? As in, speed / tempo with which something is being done.