-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cant make coexist two env in the same aws profile #26
Comments
I'm currently facing the same challenge. Any workarounds for this perhaps? |
I'm afraid not, @ChipiKaf . I still haven't figured out how to solve it. I have considered forking from this project and adapting it to my needs, but I'm still hopeful to find another solution. |
@ChipiKaf I forked from this project and created a package with the new feature of changing the prefix of the migrations table: |
Hi @dservidie . |
First of all, I wanted to thank you for your work on this tool.
I am having trouble making coexist two envs in the same AWS account, since the tables of our envs are differentiated by name.
Ex:
TableOne-Dev
TableTwo-Dev
TableOne-Prod
TableTwo-Prod
I understand the tool is thought to use the --profile dev/stage/prod. But it doesn't work in our case.
But when we want to run migrations the tool cant know what migrations were already run in Dev and what were run in Prod, since all are stored in the same place (MIGRATIONS_LOG_DB).
This forced us to duplicate the migrations naming them:
1716864675190-migration-one-DEV.mjs
and1716864675190-migration-one-PROD.mjs
, so the same database can store history for both ends in parallel.Could you please add a config that allows us to specify the env? For example:
dynamo-data-migrations up --env [Prod]
to allow us to differentiate different envs.The same could happen for other users that use your tool with two different apps. They should be careful of not having the same name in two files of their apps (unlikely, but possible)
That might be very helpful. The tool could use that env parameter to use a different table like: MIGRATIONS_LOG_DB_DEV and MIGRATIONS_LOG_DB_PROD. It might also work if the differentiation is done by adding a field like ENV to the current MIGRATIONS_LOG_DB table like:
It would also do the trick for us, If you allow us to define the name of the table where the migrations log is stored like:
dynamo-data-migrations up --log-table MIGRATIONS_LOG_DB_DEV
dynamo-data-migrations up --log-table MIGRATIONS_LOG_DB_PROD
The text was updated successfully, but these errors were encountered: