Several weeks ago, we tried our hand at building a basic Dungeons and Dragons player application powered by Django. Last time, we hooked up the app to a containerized Postgres instance. In this post I'll walk through the steps to connect a Django app to PostgreSQL in the cloud via Crunchy Bridge.
Note that in this scenario we're not actually taking the original database and moving it to Crunchy Bridge. We may have a follow-up blog post on migrating this existing database but for now we'll show how we're plugging in a new web app to a fresh instance of Postgres.
Django supports PostgreSQL 9.5 and higher as a database backend. For our app, we spun up a Postgres instance with our crunchy-postgres-appdev container. We used Python 3/Django 3.0 in a virtual environment, and with any Django-based app, we also need psycopg2 to work with the Postgres backend.
To start, I'm provisioning a new Postgres database cluster in my Crunchy Bridge account (you can sign up for an account on the Crunchy Bridge homepage). You'll be able to select the Postgres version, storage capacity, set up an initial password for postgres user, etc. Since I'm using this with a demo app, I went with one of the Hobby tiers. More details on tiers and other provisioning options are available in the docs.
After provisioning a new database cluster (which takes about a few minutes), we get the host address and port plus other details.
I can now quickly create the new database for our app on the command line like so:
createdb -U postgres -h p.s7d2ocnyg5bkvbllzckli7mwi4.db.postgresbridge.com -p 5432 ddapp
I'm naming the new database
ddapp which is the same name as our original
database. You'll see why in the next step.
We used pgModeler to design our original database; it
also allows you to export your database model to a SQL script, which I'm sharing
Like I mentioned earlier, the old database was named
ddapp, which means that
our generated script contains references for
ddapp specifically. (I certainly
could've gone with a different name, but I would have to make sure to update the
script accordingly.) We also assigned a
devuser role for the app connection,
so this script will recreate that role in this new database as well.
In Crunchy Bridge, the connection string info is comprised of the postgres
username, the password assigned when provisioning the cluster (
an example), and the postgres database. I already have the new
created, so I 'll run the
dd_database.sql script with psql and modify the
connection string like so:
psql "postgres://postgres:email@example.com:5432/ddapp" -f dd_database.sql
Now if I log in via psql (using the same connection string as above) to check, I get the tables that I wanted:
ddapp=# \dt List of relations Schema | Name | Type | Owner --------+-----------------+-------+--------- public | alignment | table | devuser public | campaign | table | devuser public | pc | table | devuser public | pc_class | table | devuser public | person | table | devuser public | person_campaign | table | devuser public | race | table | devuser (7 rows)
Then, I run the following statements so our app has all database permissions it needs:
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO devuser; GRANT ALL PRIVILEGES ON ALL sequences IN SCHEMA public TO devuser;
We're all set with Postgres, so we'll just need to finish up in Django and we'll be up and running.
We've already created our
new Django project,
so we can go ahead and update our
parameters in the project's
settings.py. Following best practices for security
we'll store our database connection information in a
.env file in our project:
settings.py we can do the following, as an example (this may look
different for you depending on how you want to manage your Django settings and
how you deploy your app):
import dj_database_url if os.environ.get('DATABASE_URL'): DATABASES['default'] = dj_database_url.config(default=os.environ['DATABASE_URL'])
We run an initial migration at this point which will create a few more database tables that Django needs:
(venv)> py manage.py migrate
Then, we can use
inspectdb to auto-generate our models based on the ddapp
(venv)> py manage.py inspectdb > managerapp/models.py
Note from the official Django docs that inspectdb isn't meant to be a definitive way of creating models. We'll still need to do some cleanup so that the database layer works as expected. (Steve wrote about our experience doing exactly this in another blog post.)
If we had gone far enough in the project to have already written our models, we'd run a migration instead. And in that case Django would do the work of setting up the schema in the new database for us. We're a Postgres shop and so we usually design the database first. Your workflow might follow what's outlined in the Django tutorial, where you start with creating models and then populate the database.
For the Pythonistas out there: Crunchy Bridge is the only cloud PostgreSQL service that includes PL/Python and libraries like SciPy and NumPy out of the box, with more to come. It's easy to get started by creating an account; if you have questions feel free to contact or tweet at us.
You may be interested in our PL/Python content:
- Getting Started with Postgres Functions in PL/Python
- Postgres Data Types in PL/Python
- Exploring PL/Python: Turn Postgres Table Data Into a NumPy Array
- Building a recommendation engine inside Postgres with Python and Pandas
And here are the other posts so far in our Django series:
October 30, 2020 •More by this author