-
Notifications
You must be signed in to change notification settings - Fork 4
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
Extend the local stack script to pg_dump and restore the local DB #1280
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding these new commands and functionality to the local stack, they really make switching between diff local environments & ldm work much easier! 🚢 ✨
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ran through the steps and 👍🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks and works great Mike.
I have one question though: You've added support to dump the local DB into the dumps
directory, and you've added support to specify the filename that you're going to use to replicate into from the live DB and to restore from. Is the intent that if you want to load a local dump file you have handy into your DB for you to copy it into the snapshots folder and then replicate-db
with the -f
arg pointing at it?
I guess put another way, is the intent to make it a manual operation to promote a local dump file into a snapshot that you can use by mv
ing it from atd-vzd/dumps
to atd-vzd/snapshots
?
If so, that's totally cool, I'm just curious if I am getting the whole picture.
Thanks!! 🚢 🚢 🚢
"remove-snapshots", | ||
"hasura-console" | ||
], | ||
) | ||
parser.add_argument("-f", "--filename", required=False) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first, I was going to suggest something more specific that describes what the file needs to be, but then I realized that you can only use the -f
flag meaningfully after the replicate-db
command, so 👍.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool - thanks for the sanity check 🙏
if(args.filename): | ||
snapshotFilename = args.filename | ||
else: | ||
today = date.today().strftime("%Y-%m-%d") | ||
snapshotFilename = ( | ||
"visionzero_" + today + "_" + ( | ||
"with-change-log" if args.include_change_log_data else "without-change-log") + ".sql" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reallllly like that you can specify a filename to be used when pulling data down from the production machine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding my concurrence based on Dev reviews 💎
@frankhereford Yeah, it does involve manually moving files between the |
@mddilley wrote:
I think it's great just the way it is. I just wanted to make sure I wasn't missing anything. This is top shelf stuff. |
Associated issues
This splits out the local tooling updates from #1274 so that we can get this merged into master sooner. It is intended to help out with the LDM local dev cycle.
Testing
URL to test:
Local
Steps to test:
./vision-zero replicate-db
/atd-vzd/snapshots/
with today's date./vision-zero dump-local-db
to pg_dump the local DB/atd-vzd/dumps/
./vision-zero replicate-db -f <your data dump filename>.sql
to restore into the local DB. Totally open to suggestions on changing up the command arguments. 🙏 I just went with-f
to get it working.Ship list