You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! First of all, thanks for sharing this suite of tools.
Would you be open to allowing the table name used for storing migrations to be customised? This would be useful if you're using Postgres schemas, so that __migrations__ becomes schema1.__migrations__, for example.
Also, when do you typically run migrations? Do you have any experience with automatically running migrations after the function is deployed?
Thanks again!
The text was updated successfully, but these errors were encountered:
Customizing the migrations table name should be relatively easy to do. Would you like to create a PR?
As for when to run migrations, they can be run before or after the functions are deployed, it all depends on how forwards/backwards compatible you make your migrations/handlers.
I normally run them before the functions are deployed in-case I have added new columns that are expected to exist. However there are cases where you will want to run them after, for instance when dropping a column. Although if you automate deployment and migrations with CI, you may want to deploy in multiple commits to ensure your schema and code are compatible.
Hi! First of all, thanks for sharing this suite of tools.
Would you be open to allowing the table name used for storing migrations to be customised? This would be useful if you're using Postgres schemas, so that
__migrations__
becomesschema1.__migrations__
, for example.Also, when do you typically run migrations? Do you have any experience with automatically running migrations after the function is deployed?
Thanks again!
The text was updated successfully, but these errors were encountered: