Hi Ken!
Thanks for your reply so far.
PgAdmin seems incompatible with my window manager (Wayland, Gnome) on my operating system (Manjaro Linux). Other Linux users are reporting similar issues. After spending much time troubleshooting I resolved to using psql to analyze my tables instead.
On Heroku I am paying for two separate postgres silos currently - - one instance for my testing pipeline with placeholder content and the other instance for my real production content.
For now I am working with my testing db instance in my local development environment.
I entered some lorem ipsum data into my ‘articles’ (app)’s Article model objects. When navigating to that app’s url location, Django serves the templates as expected. Success! That tells us that I am doing something right (so far). This app works.
In the output below, you will see the schema for the tables for all three of my Django projects. It’s a fairly long list I guess. But I can draw your attention to the entry named “articles_article”. That is the “articles” app and “Article” model mentioned earlier. That is present which explains why I was able to get it working above.
The problem I am trying to address involves the ‘contents’ app’s ‘PageContent’ model. As you can see in the psql output below, no such data entries exist yet. This confirms the migrations are not being applied/instantiated.
It’s also worth pointing out that you will see lots of entries with ‘contents’ app names but that is because I have an app with the same name for a different Django project. At first I thought using the same app name for two different Django projects was the issue, but then I noticed with the nomenclature, there is an underscore which further distinguishes each table entry. So for my current app, I should see “contents_pagecontents” which is unique and distinct without overlapping with any of the other Django projects. But no such entry exists.
The above is my best analysis / examination of the issue with my db and I don’t think I am any further along to identifying a potential solution. What else might you extrapolate based on what you see above? What other psql commands would you recommend to clarify the issue, @KenWhitesell?
To collect the output below, I leveraged this official postgresql doc: PostgreSQL: Documentation: 16: psql
Here is the output discussed above:
<project-name>::DATABASE=> \d+
List of relations
Schema | Name | Type | Owner | Persistence | Access method | Size | Description
--------+-----------------------------------+----------+----------------+-------------+---------------+------------+-------------
public | accounts_authtoggle | table | <redacted> | permanent | heap | 40 kB |
public | accounts_authtoggle_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | accounts_passphrase | table | <redacted> | permanent | heap | 40 kB |
public | accounts_passphrase_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | articles_article | table | <redacted> | permanent | heap | 16 kB |
public | articles_article_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | auth_group | table | <redacted> | permanent | heap | 0 bytes |
public | auth_group_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | auth_group_permissions | table | <redacted> | permanent | heap | 0 bytes |
public | auth_group_permissions_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | auth_permission | table | <redacted> | permanent | heap | 48 kB |
public | auth_permission_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | auth_user | table | <redacted> | permanent | heap | 48 kB |
public | auth_user_groups | table | <redacted> | permanent | heap | 0 bytes |
public | auth_user_groups_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | auth_user_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | auth_user_user_permissions | table | <redacted> | permanent | heap | 0 bytes |
public | auth_user_user_permissions_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | contents_content | table | <redacted> | permanent | heap | 0 bytes |
public | contents_content_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | contents_gatewayprotect | table | <redacted> | permanent | heap | 0 bytes |
public | contents_gatewayprotect_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | contents_induction | table | <redacted> | permanent | heap | 8192 bytes |
public | contents_induction_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | contents_preamble | table | <redacted> | permanent | heap | 8192 bytes |
public | contents_preamble_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | contents_research | table | <redacted> | permanent | heap | 8192 bytes |
public | contents_research_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | contents_scriptsuggestion | table | <redacted> | permanent | heap | 8192 bytes |
public | contents_scriptsuggestions_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | contents_stockscript | table | <redacted> | permanent | heap | 8192 bytes |
public | contents_stockscript_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | django_admin_log | table | <redacted> | permanent | heap | 56 kB |
public | django_admin_log_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | django_content_type | table | <redacted> | permanent | heap | 40 kB |
public | django_content_type_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | django_migrations | table | <redacted> | permanent | heap | 48 kB |
public | django_migrations_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | django_session | table | <redacted> | permanent | heap | 72 kB |
public | essays_bibliographyarticle | table | <redacted> | permanent | heap | 48 kB |
public | essays_bibliographyarticle_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | essays_contentchanges | table | <redacted> | permanent | heap | 48 kB |
public | essays_contentchanges_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | essays_curatedslashdot | table | <redacted> | permanent | heap | 48 kB |
public | essays_curatedslashdot_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | essays_curatedwatchtower | table | <redacted> | permanent | heap | 48 kB |
public | essays_curatedwatchtower_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | essays_essayarticle | table | <redacted> | permanent | heap | 48 kB |
public | essays_essayarticle_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | essays_objectionsarticle | table | <redacted> | permanent | heap | 8192 bytes |
public | essays_objectionsarticle_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | generators_generator | table | <redacted> | permanent | heap | 120 kB |
public | generators_generator_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | landings_aboutcontent | table | <redacted> | permanent | heap | 48 kB |
public | landings_aboutcontent_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | landings_essaylist | table | <redacted> | permanent | heap | 48 kB |
public | landings_essaylist_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
public | landings_howto | table | <redacted> | permanent | heap | 48 kB |
public | landings_howto_id_seq | sequence | <redacted> | permanent | | 8192 bytes |
(59 rows)
Creating a new db is costly. There has to be a way to reset my app’s tables with the same db: for example using $ python manage.py migrate contents zero which restores the contents’ app to its original state. It’s also worth pointing out that it’s a good thing I backed up my ‘migrations’ directory instead of deleting it. So with some cp and mv operations, everything is back to its original state.