Create a script that can connect to a target database on the remote server and do the following
Create a database role/user (they are the same in postgres) that will be used by the Mobile App's server ONLY to read and write from a subset of the database tables.
Optional, but nice: Verify using SELECT statements that all the necessary tables exist and have the correct permissions. If possible, print out debugging information about what was found
Suggested steps
Step 1: Familiarize yourself with the postgres roles and users such that you can create a role for your app that as ONLY the needed permissions and not extra permissions. We don't want the database user for the mobile app, for example, to accidentally wreck some data in say the cecase table.
Step 2: Work out the required commands during an interactive session with posgres, such as with psql -d cogdb and only after you have all the correct steps, then transform each command to work in a shell script that can be run by, say, a python program. Check out the gnu bash scripting guide
Step 3: Test your tool on the target migration database at ..84.209 using user chen1chen2. Since this is not yet in production, your tool can make a mistake without hurting actual data. Even though there is actual data in the db, it's a copy of the production database.
Other TODOs
Figure out how to get the app to mobile devices in Pittsburgh for testing. Playstore?
Goal
Create a script that can connect to a target database on the remote server and do the following
Suggested steps
Step 1: Familiarize yourself with the postgres roles and users such that you can create a role for your app that as ONLY the needed permissions and not extra permissions. We don't want the database user for the mobile app, for example, to accidentally wreck some data in say the
cecasetable.Step 2: Work out the required commands during an interactive session with posgres, such as with
psql -d cogdband only after you have all the correct steps, then transform each command to work in a shell script that can be run by, say, a python program. Check out the gnu bash scripting guideStep 3: Test your tool on the target migration database at ..84.209 using user
chen1chen2. Since this is not yet in production, your tool can make a mistake without hurting actual data. Even though there is actual data in the db, it's a copy of the production database.Other TODOs