After we have run the previous command, we can use the PostgreSQL command-line tools or any other application that allows us to easily check the contents of a PostreSQL database, to check the tables that Django generated. If you decided to continue working with SQLite, we already learned how to check the tables in the previous chapters.

Run the following command to list the generated tables:

psql --username=username --dbname=drones --command="dt"

The following lines show the output with all the generated table names:

                       List of relations
     Schema |            Name            | Type  |  Owner   
    --------+----------------------------+-------+----------
     public | auth_group                 | table | username
     public | auth_group_permissions     | table | username
     public | auth_permission            | table | username
     public | auth_user                  | table | username
     public | auth_user_groups           | table | username
     public | auth_user_user_permissions | table | username
     public | django_admin_log           | table | username
     public | django_content_type        | table | username
     public | django_migrations          | table | username
     public | django_session             | table | username
     public | drones_competition         | table | username
     public | drones_drone               | table | username
     public | drones_dronecategory       | table | username
     public | drones_pilot               | table | username
    (14 rows)
  

In our previous example, Django used the toys_ prefix for the table related to the toys application we had created. In this case, the application name is drones, and therefore, Django uses the drones_ prefix for the following four tables that are related to the application:

• drones_drone: This table persists the Drone model
• drones_dronecategory: This table persists the DroneCategory model
• drones_pilot: This table persists the Pilot model
• drones_competition: This table persists the Competition model

Django's integrated ORM generated these tables and the foreign keys based on the information included in our models and the code generated during the migrations process.

The following commands will allow you to check the contents of the four tables after we compose and send different HTTP requests to the RESTful Web Service, and these calls end up making CRUD operations to the four tables. The commands assume that you are running PostgreSQL on the same computer in which you are running the command:

    psql --username=username --dbname=drones --command="SELECT * FROM drones_dronecategory;"
    psql --username=username --dbname=drones --command="SELECT * FROM drones_drone;"
    psql --username=username --dbname=drones --command="SELECT * FROM drones_pilot;"
    psql --username=username --dbname=drones --command="SELECT * FROM drones_competition;"

As happened in our previous example, Django generated additional tables that it requires to support the web framework and the authentication features that we will use later.