Search code examples
herokudjango-models

local migrations not showing up on heroku


I know this question has been asked before however, my issue is a bit different from those problems. I am working on a project and added a few attributes to different models in different apps and I did migrations gradually. and everything worked fine. I created a PR on a forked public branch and my client merged my branch into a testing branch.

Now the issue is that Heroku is not recognizing the migrations on the remote server.

I am using sqlite3 on my local development environment and PostgreSQL on the production environment.

Is Heroku serving the sqlite3 or PostgreSQL on production? or what can be the main issue?

NOTE : I am added as a collaborator and can't pull the local changes to the remote server and hence can't deploy the local changes to remote server.

UPDATE

the result of git remote -v

heroku  https://git.heroku.com/tarot-testing.git (fetch)
heroku  https://git.heroku.com/tarot-testing.git (push)
master  https://github.com/abubakarA-Dot/tarot_juicer.git (fetch)
master  https://github.com/abubakarA-Dot/tarot_juicer.git (push)
origin  https://github.com/abubakarA-Dot/tarot_juicer.git (fetch)
origin  https://github.com/abubakarA-Dot/tarot_juicer.git (push)
upstream        https://github.com/enoren5/tarot_juicer.git (fetch)
upstream        https://github.com/enoren5/tarot_juicer.git (push)

Solution

  • @djangodeveloper and I are on the same team working on the same project on GitHub.

    The three methods for migrating a db on Heroku discussed in the comments so far include:

    1. Running $ heroku run python manage.py migrate
    2. Adding some paramaters to the Procfile
    3. Install a third party (unofficial) Buildpack

    Here is one more method to consider (the one that I use):

    1. Run a remote AWS Postgres db locally.

    It's as straightforward as running:

    (local venv) $ export DATABASE_URL='postgres://USER:PASSWORD@HOST:PORT/NAME'
    

    You can locate the DATABASE_URL with all the right variables specified inside the Heroku dashboard after revealing the config vars. All you need to do to get it working is to copy and paste that config var into your shell within the quotes. For a more in-depth explanation of how to use this technique, you can view the documentation in our GitHub project’s README.md at the heading titled: “#3. Handling db remote instances but locally”. Using this technique, after having exported the db in my local development environment, I ran:

    (local venv) $ python manage.py migrate
    Database Config: {'default': {'NAME': <redacted>, 'USER': <redacted>, 'PASSWORD': <redacted>, 'HOST': '<redacted>', 'PORT': 5432, 'CONN_MAX_AGE': 600, 'ENGINE': 'django.db.backends.postgresql_psycopg2'}}
    Operations to perform:
      Apply all migrations: accounts, admin, auth, contenttypes, essays, generators, landings, sessions
    Running migrations:
      Applying essays.0007_auto_20221107_2032... OK
      Applying essays.0008_auto_20221108_0627... OK
      Applying generators.0004_generator_is_published... OK
      Applying generators.0005_alter_generator_is_published... OK
      Applying landings.0005_auto_20221107_1312... OK
      Applying landings.0006_auto_20221108_0627... OK
    

    As you can see in the output at the bottom, the database has now been migrated successfully. In the Django Admin Dashboard, I can see all the data was preserved. Although there are new issues with the generators web app which will need to be handled separately outside the scope of the OP’s original question. The staging version of the site otherwise is running beautifully now.

    Back in September when Heroku began notifying their users that the free PostgreSQL and Hobby dynos were being phased out, I proactively moved both our staging and production PostgreSQL databases to Basic tiers costing $9.00/mo for each. I didn’t lose any data and the transition so far has been seamless.

    While the OP in the comment section shared his experience with a different Heroku project with PostgreSQL becoming unavailable and encountering data loss, I can confirm that was never the case with this project.

    To this end, have a look at this output:

    $ heroku pg:info -a tarot-testing
    === DATABASE_URL, COPPER_TESTING_URL
    Plan:                  Basic
    Status:                Available
    Connections:           8/20
    PG Version:            14.6
    Created:               2022-10-02 13:50 UTC
    Data Size:             11.1 MB/10.00 GB (In compliance)
    Tables:                28
    Rows:                  351/10000000 (In compliance)
    Fork/Follow:           Unsupported
    Rollback:              Unsupported
    Continuous Protection: Off
    Billing App:           tarot-prod
    Add-on:                postgresql-lorem-2
    

    As you can see, it was created on October 2nd (well before the change-over deadline at the end of November) and it is populated with some data.

    Here is a screenshot from our project's Heroku Dashboard showing further proof that our PostreSQL is online and configured properly:

    enter image description here