Skip to content
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

Added always_confirm_no option #39

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

dsmurrell
Copy link

I could have missed something, but I didn't see an option to, without manual intervention, confirm 'no' to some required migration.

We have a situation where evolve is run remotely and we wanted to automatically confirm 'no' if a migration was required to allow the program to not wait forever. Setting interactive=False would always enact the migration.

Is there another way of doing this currently?

The only thing that doesn't quite gel with this addition is that to get the bright red output:

Making updates to database: dbname

interactive needs to be True with a call like db.evolve(interactive=True, always_confirm_no=True)

and this seems weird if you're using this option for automated operation. Was there a reason you only output "Making updates to database: dbname" if interactive is True?

@dsmurrell
Copy link
Author

Sorry, I couldn't seem to run the tests locally as I kept getting peewee.OperationalError: (1045, "Access denied for user 'user'@'localhost' (using password: NO)")

@keredson
Copy link
Owner

so this would be as a no-op check during deployment, right?

if so, yeah, makes sense. but not crazy about always_confirm_no. maybe confirm_noop? fail_if_not_current? let's brainstorm names, open to other suggestions.

@keredson
Copy link
Owner

re local testing, where did it fail w/ that? at createdb peeweedbevolve_test? can you open a bug w/ the stacktrace? at min i should doc steps or catch and give better error.

@dsmurrell
Copy link
Author

It does this for a while (about 5 times the amount in that screenshot)...

Screenshot 2019-11-21 at 11 25 15

and then it does this without stopping...

Screenshot 2019-11-21 at 11 26 21

and when I ctrl-c out it does this...

Screenshot 2019-11-21 at 11 27 08

Let me know if there is a way I can provide more info. It seems that I'm not giving the right password etc to my local postgres instance, but I'm not sure how to do that in the tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants