質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.51%
Django

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

SQLite

SQLiteはリレーショナルデータベース管理システムの1つで、サーバーではなくライブラリとして使用されている。

PostgreSQL

PostgreSQLはオープンソースのオブジェクトリレーショナルデータベース管理システムです。 Oracle Databaseで使われるPL/SQLを参考に実装されたビルトイン言語で、Windows、 Mac、Linux、UNIX、MSなどいくつものプラットフォームに対応しています。

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

Q&A

解決済

3回答

10143閲覧

django.db.utils.ProgrammingError: relation "auth_user" does not exist の解決

Lim-Nic

総合スコア18

Django

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

SQLite

SQLiteはリレーショナルデータベース管理システムの1つで、サーバーではなくライブラリとして使用されている。

PostgreSQL

PostgreSQLはオープンソースのオブジェクトリレーショナルデータベース管理システムです。 Oracle Databaseで使われるPL/SQLを参考に実装されたビルトイン言語で、Windows、 Mac、Linux、UNIX、MSなどいくつものプラットフォームに対応しています。

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

0グッド

0クリップ

投稿2020/07/31 01:42

編集2020/07/31 07:54

前提・実現したいこと

Djangoアプリをherokuにデプロイする為、SqliteからPostgreSQLに移行しています。
デプロイ後アクセスすると、以下のようなエラーが表示されます。

発生している問題・エラーメッセージ

django.db.utils.ProgrammingError: relation "auth_user" does not exist LINE 1: ...user"."is_active", "auth_user"."date_joined" FROM "auth_user...

試したこと

① setting.py の ALLOWED_HOSTS = [] にしてローカル動作させると
正常に動作するのを確認しました。

② PostgreSQLのDBを drop database で削除し、再度作成。
makemigrations ⇒ migrate を行いました。マイグレーションは成功していますが
デプロイ、アクセスすると同じエラーが表示されます。

③ PostgreSQLのDB内に auth_user が存在している事を確認しました。
python manage.py migrate auth を実行すると、内容に差異はないと表示されます。

④ Django のsuperuser を設定し忘れているのかと思いましたが、作成しても同じエラーが表示されました。

⑤ Herokuのアプリケーションを何度か削除、作成を繰り返してみましたが同じエラーが表示されました。

調べたが分からない事

https://teratail.com/questions/270985
上記質問のような、アプリを再度作り直したら動作しました。
の”アプリを作り直す”は完全にアプリを削除、1から作成ということでしょうか。
今回のようにアプリを作ってからデプロイする場合は、どうやって作り直せばいいのでしょうか。

補足情報(FW/ツールのバージョンなど)

PostgreSQL 11.2
Python 3.8.5

asgiref==3.2.3
beautifulsoup4==4.9.1
cycler==0.10.0
dj-database-url==0.5.0
Django==3.0.3
django-bootstrap4==2.1.1
django-heroku==0.3.1
gunicorn==20.0.4
kiwisolver==1.1.0
matplotlib==3.2.0
numpy==1.18.1
Pillow==7.2.0
psycopg2==2.8.5
pyparsing==2.4.6
python-dateutil==2.8.1
pytz==2019.3
six==1.14.0
soupsieve==2.0.1
sqlparse==0.3.0
whitenoise==5.1.0

その他必要な情報があれば教えて下さい。

###補足内容画像

イメージ説明
イメージ説明

psql -U admin -d ****
\d auth_user

の結果

テーブル "public.auth_user" 列 | 型 | 照合順序 | Null 値を許容 | デフォルト --------------+--------------------------+----------+---------------+--------------------------------------- id | integer | | not null | nextval('auth_user_id_seq'::regclass) password | character varying(128) | | not null | last_login | timestamp with time zone | | | is_superuser | boolean | | not null | username | character varying(150) | | not null | first_name | character varying(30) | | not null | last_name | character varying(150) | | not null | email | character varying(254) | | not null | is_staff | boolean | | not null | is_active | boolean | | not null | date_joined | timestamp with time zone | | not null |

models.py

import datetime from django.db import models from django.utils import timezone class Schedule(models.Model): """スケジュール""" summary = models.CharField('概要', max_length=50) description = models.TextField('詳細な説明', blank=True) start_time = models.TimeField('開始時間', default=datetime.time(7, 0, 0)) end_time = models.TimeField('終了時間', default=datetime.time(7, 0, 0)) date = models.DateField('日付') created_at = models.DateTimeField('作成日', default=timezone.now) user_name = models.CharField('登録者', max_length=50) def __str__(self): return self.summary class OptionItems(models.Model): """カレンダーのオプション""" option_time = models.TimeField('1日の開始時間', default=datetime.time(0, 0, 0)) user_name = models.CharField('登録者', max_length=50) class OptionFriend(models.Model): friend_name = models.CharField('フレンド', max_length=50) user_name = models.CharField('登録者', max_length=50) class Group(models.Model): Group_name = models.CharField('グループ名', max_length=50) description = models.TextField('詳細な説明', blank=True) member = models.TextField('メンバー', blank=True) user_name = models.CharField('登録者', max_length=50) class Friend(models.Model): """フレンド""" name = models.CharField(max_length=100) mail = models.EmailField(max_length=200) gender = models.BooleanField() age = models.IntegerField(default=0) birthday = models.DateField() def __str__(self): return '<Friend:id=' + str(self.id) + ',' + self.name + '(' + str(self.age) + ')>'

migrations 0001_initial.py

# Generated by Django 2.1.5 on 2019-01-11 04:04 import datetime from django.db import migrations, models import django.utils.timezone class Migration(migrations.Migration): initial = True dependencies = [ ] operations = [ migrations.CreateModel( name='Schedule', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('summary', models.CharField(max_length=50, verbose_name='概要')), ('description', models.TextField(blank=True, verbose_name='詳細な説明')), ('start_time', models.TimeField(default=datetime.time(7, 0), verbose_name='開始時間')), ('end_time', models.TimeField(default=datetime.time(7, 0), verbose_name='終了時間')), ('date', models.DateField(verbose_name='日付')), ('created_at', models.DateTimeField(default=django.utils.timezone.now, verbose_name='作成日')), ], ), ]

migrations 0002_auto_20200731.py

# Generated by Django 3.0.3 on 2020-07-31 00:54 import datetime from django.db import migrations, models class Migration(migrations.Migration): dependencies = [ ('app', '0001_initial'), ] operations = [ migrations.CreateModel( name='Friend', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('name', models.CharField(max_length=100)), ('mail', models.EmailField(max_length=200)), ('gender', models.BooleanField()), ('age', models.IntegerField(default=0)), ('birthday', models.DateField()), ], ), migrations.CreateModel( name='Group', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('Group_name', models.CharField(max_length=50, verbose_name='グループ名')), ('description', models.TextField(blank=True, verbose_name='詳細な説明')), ('member', models.TextField(blank=True, verbose_name='メンバー')), ('user_name', models.CharField(max_length=50, verbose_name='登録者')), ], ), migrations.CreateModel( name='OptionFriend', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('friend_name', models.CharField(max_length=50, verbose_name='フレンド')), ('user_name', models.CharField(max_length=50, verbose_name='登録者')), ], ), migrations.CreateModel( name='OptionItems', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('option_time', models.TimeField(default=datetime.time(0, 0), verbose_name='1日の開始時間')), ('user_name', models.CharField(max_length=50, verbose_name='登録者')), ], ), migrations.AddField( model_name='schedule', name='user_name', field=models.CharField(default=1, max_length=50, verbose_name='登録者'), preserve_default=False, ), ]

エラーが起こったと思われる場所
イメージ説明

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

sazi

2020/07/31 01:59

ログインしているユーザー名と同名のスキーマが存在したりしていませんか?
Lim-Nic

2020/07/31 02:17

すみません。あまりDBに関して無知なもので、属性・・・テーブルの構成をアップすればよろしいでしょうか リレーション一覧 スキーマ | 名前 | 型 | 所有者 ----------+----------------------------+----------+-------- public | app_friend | テーブル | admin public | app_group | テーブル | admin public | app_optionfriend | テーブル | admin public | app_optionitems | テーブル | admin public | app_schedule | テーブル | admin public | auth_group | テーブル | admin public | auth_group_permissions | テーブル | admin public | auth_permission | テーブル | admin public | auth_user | テーブル | admin public | auth_user_groups | テーブル | admin public | auth_user_user_permissions | テーブル | admin public | django_admin_log | テーブル | admin public | django_content_type | テーブル | admin public | django_migrations | テーブル | admin public | django_session | テーブル | admin
Lim-Nic

2020/07/31 02:19

間違っていたらすみません。 Djangoには admin でsuperuserを作成してそのアカウントでログインしています。 postgresqlは admin で管理アカウントを作成しています。
Lim-Nic

2020/07/31 02:33

同様のコマンドを実行したのですが、 Running migrations: No migrations to apply. と表示されるので、DB内には存在はしているようです。(内容がきちんと正しいモノなのかは判断できません、間違った内容でmigrateしようとしてるのかもしれないですし)
sazi

2020/07/31 02:38

因みに、DBツールで、プログラムでログインしているユーザーでログインし、 select * from auth_user とした場合エラーにはなりませんか? 一番いいのは、プログラムで生成されているSQLを抜き出して試すのが良いのですが。
sazi

2020/07/31 02:40

因みに、エラーで出力されているSQLでは項目やテーブルが"で括られていますが、"で括ると大文字小文字も厳密に判断されます
Lim-Nic

2020/07/31 02:44

すみません。DBツールというのが分からなくて、どのことでしょうか。 cmdで psql -U postgres ではなさそうですね。 Djangoの管理者ページでしょうか。
sazi

2020/07/31 02:47

cmdでも良いですよ。 DBツールはpgadminとかです。
Lim-Nic

2020/07/31 02:50

select * from auth_user で調べるとDjangoの管理ページでやっている人が居ました。 ですが、本番環境ではログインした次のDB管理ページを読み込むところで質問内容のエラーが出るので 管理ページでは出来なさそうです。 pgadmin、Posgreをインストールした時についてきたやつですね。早急に試します
Lim-Nic

2020/07/31 02:55 編集

結局cmdで試しました。 そのままアップできる内容ではなさそうですが id/password/lastlogin/・・・・などの情報が1行出てきました。 username:admin メールアドレスやログイン情報などを見ても作成したもので間違いないです。
sazi

2020/07/31 02:57

後はプログラムで生成されているSQLでの確認ですね。
Lim-Nic

2020/07/31 03:01

すみません、その方法が紹介されているサイトか、ヒントになる言葉を教えて頂けないでしょうか。 任せきりで申し訳ないです。 お昼なので、13:00に改めて報告します。
Lim-Nic

2020/07/31 04:30 編集

すみません、苦戦してます ただ単にView.pyでmodelsにの内容を取得して表示するということでしょうか 例えば、プログラム内で queryset = OptionFriend.objects.filter(user_name=user) という感じでuserに合わせてDBの検索結果を絞り込むことをしていますが、これと同じですかね。 これを本番環境下で、アクセスできるページ上に表示するのかな?
sazi

2020/07/31 04:49

Postgres側の設定でSQLTraceを有効にして確認する方法もありはしますが。
Lim-Nic

2020/07/31 04:56

多分分かりました。 Djangoの管理画面が日本語だったので気付いてませんでした。 恐らくですが、https://django-book.readthedocs.io/en/latest/chapter06.html こちらの図6-3。ユーザー変更リストページ のような画面を確認すれば良いということですかね。 ローカル環境http://127.0.0.1:8000/admin/auth/user/で確認すると postgreで確認した時と同じ username:admin メールアドレスも同じものが出てきました。 Django内のsuperuserの設定ですね。 本番環境で確認しようとしましたが、http://*****/admin/のログイン画面から ログインボタンを押すと強制的にエラーの画面に映るので確認できませんでした。
Lim-Nic

2020/07/31 05:00

ちなみに、$ python manage.py inspectdb でDBの中を確認したところ  class AuthUser(models.Model): password = models.CharField(max_length=128) last_login = models.DateTimeField(blank=True, null=True) is_superuser = models.BooleanField() username = models.CharField(unique=True, max_length=150) first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=150) email = models.CharField(max_length=254) is_staff = models.BooleanField() is_active = models.BooleanField() date_joined = models.DateTimeField() という項目があるので、枠組み自体は存在していそうです。中身までは見れませんでした。 Django shellで確認しようとしましたが >>> print(AuthUser.objects.all().query) Traceback (most recent call last): File "<console>", line 1, in <module> NameError: name 'AuthUser' is not defined 書き方が違うのでしょうか、エラーになっています。 他のDBの内容でやっても同じなので私のやり方の問題だと思いますが・・・
Lim-Nic

2020/07/31 05:11

上記のエラーについて、分かりました。 実行してみると >>> from django.contrib.auth.models import User >>> print(User.objects.all().query) SELECT "auth_user"."id", "auth_user"."password", "auth_user"."last_login", "auth_user"."is_superuser", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."date_joined" FROM "auth_user" ここまで出ました。
sazi

2020/07/31 05:13

それを直接SQLとして実行してみてください。 同じエラーが出るなら大文字/小文字やスペルを確認して下さい。
Lim-Nic

2020/07/31 05:37

関数での書き方は紹介されているのですが、cmdで実行する方法がよく分からないです・・・。 >>> from django.db import connection >>> from django.contrib.auth.models import User >>> a = User.objects.raw('SELECT * FROM auth_user') >>> cursor.execute("SELECT * FROM ") ←書き方が分からない??? cursor.executeが使えそうな気がするのですが。 https://docs.python.org/ja/3/library/sqlite3.html この内容はsqlite3なので今回は違いますよね? 色々試しすぎて、どこの何を確認しようとしているのか分からなくなってきました
sazi

2020/07/31 05:39

コンソールかDBツールで実行して下さい。
Lim-Nic

2020/07/31 05:51

うーん。すみません。もう少し詳しく教えて頂けませんか。 質問の中に、新しくエラー画面の情報の一部をアップします。 その内容で何か手篝になりそうなものありませんか。
sazi

2020/07/31 05:59

「relation "auth_user" does not exist」はテーブルが無いというエラーなので、スキーマが違って参照できないか、名前が違うとしか思えないのです。 スキーマはPublicしか存在しないようなので、名前が違う可能性が大です。 なので、プログラムで作成されたSQLを直接DBMSに問い合わせた結果を確認した方が早いと思ったのです。 エラーにならなかった場合は、Django周りという事でお役には立てませんが。
quickquip

2020/07/31 06:07

> PostgreSQLのDB内に auth_user が存在している事を確認しました。 質問にこう書いてありますがこれはどうやって確認したのですか? これが確認できる人が「コンソールかDBツールで実行して下さい。」と言われてわからないのが不思議です。
quickquip

2020/07/31 06:16 編集

PostgreSQLのDBツールといえば psql かと思います。 ”Run console" で psql DB名 でコンソールに入れるんじゃないでしょうか。 \d auth_user の結果を貼ってもらえるといいかと思います。
Lim-Nic

2020/07/31 06:34

こちらの内容でしょうか テーブル "public.auth_user" 列 | 型 | 照合順序 | Null 値を許容 | デフォルト --------------+--------------------------+----------+---------------+--------------------------------------- id | integer | | not null | nextval('auth_user_id_seq'::regclass) password | character varying(128) | | not null | last_login | timestamp with time zone | | | is_superuser | boolean | | not null | username | character varying(150) | | not null | first_name | character varying(30) | | not null | last_name | character varying(150) | | not null | email | character varying(254) | | not null | is_staff | boolean | | not null | is_active | boolean | | not null | date_joined | timestamp with time zone | | not null |
quickquip

2020/07/31 06:38 編集

回答に必要であろう情報は全部質問に追記してください (内容は私の意図と合ってます)
Lim-Nic

2020/07/31 06:45

次に必要な作業を教えて頂けませんか
sazi

2020/07/31 06:58 編集

出力されているSQLをコンソールから入力してエラーにならないかどうか確認して下さい。 その際、コンソールへはプログラムで使用しているユーザーでログインして下さい。
Lim-Nic

2020/07/31 07:27

入力する為の構文について教えて下さい。 出力されているSQLは 上記の>>>\d auth_user のことですよね コンソールから入力は 上記と同じ方法でコマンド(SQLをそのまま?)を入力することですよね。 cursor.execute というコマンドなのかと思ったのですが、やり方が分からず間違っているのでしょうか。 id, password, とそのまま打つのは違いますよね。 すみません。手あたり次第試しながら回答しているので、 用語の整理や自分が何をしているのか理解が追い付いていないです。
sazi

2020/07/31 07:28

> 出力されているSQLは 上記の>>>\d auth_user のことですよね いえ違います。エラーとなっているSQLです。
quickquip

2020/07/31 07:37 編集

models.pyとmigrationsの中のファイル全部、あるいは何をやったのかの全手順が要りそうですね。 エラーの意味はハッキリしているのですが、なんでそんなことになっているのか? が謎です。 推測としては、models.pyの`AuthUser`に`auth_user=models.????Field(????)`という行を追加したあと、makemigrationsしてないのでは? という感じなのですが質問とは食い違います。
Lim-Nic

2020/07/31 07:45 編集

すみません。エラーとなっているSQLが分かりません。 auth_userのことではないのでしょうか。 それほどの知識しかなくて、イライラさせてしまっていたらすみません。 ひとまず、models.pyとmigrationsの内容をアップしました。
sazi

2020/07/31 07:52 編集

DjangoによってSQLが組み立てられて、そのSQLを発行した時に「relation "auth_user" does not exist」というエラーになっている訳です。 なので、エラーになっているだろうSQLを直接実行してみてエラーになるかどうかを確認しようとしている訳です。 エラーにならなければ、そもそもエラーになっているのはそのSQLじゃないかもしれませんし。 取り敢えずSQLの確認は置いておいて、migrationに関する事を確認した方が良さそうですね。
Lim-Nic

2020/07/31 07:52

/app/.heroku/python/lib/python3.8/site-packages/django/db/backends/utils.py in _execute def _execute(self, sql, params, *ignored_wrapper_args): self.db.validate_no_broken_transaction() with self.db.wrap_database_errors: if params is None: # params default might be backend specific. return self.cursor.execute(sql) else: return self.cursor.execute(sql, params)  <<<ここでエラー 上記でエラーになっていると思われるのですが、その場合 self.cursor.execute(sql, params) を実行するということでしょうか
quickquip

2020/07/31 08:09 編集

auth_userというテーブルにからauth_userというカラム(relation)を含むデータを取り出そうとして、auth_userというカラムがないというエラーが起きていて、実際auth_userテーブルにauth_userというカラムがないので、そこに不思議はないです。
quickquip

2020/07/31 08:09 編集

AuthUserというモデルクラスを定義していないでしょうか? 自分で作っていなければなにかmiddlewareでしょうか。 django.contrib.adminやdjango.contrib.authで使われているテーブル名ではないと思ったので、てっきり質問者さんが定義したのかと(わたしの勘違い?)
Lim-Nic

2020/07/31 08:12

少なくとも私自身で定義していないです。 定義したのはmodels.pyの内容のみです。
Lim-Nic

2020/07/31 08:24 編集

pyhotn manage.py inspectdb を実行すると、 class AuthUser(models.Model): password = models.CharField(max_length=128) last_login = models.DateTimeField(blank=True, null=True) is_superuser = models.BooleanField() username = models.CharField(unique=True, max_length=150) first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=150) email = models.CharField(max_length=254) is_staff = models.BooleanField() is_active = models.BooleanField() date_joined = models.DateTimeField() class Meta: managed = False db_table = 'auth_user' この内容が出てきます。全体は文字数の関係上アップできないですが。 これってDjangoのアカウント情報の事ですよね。管理画面で設定したりsuperuserのような。
quickquip

2020/07/31 08:33 編集

すみません、勘違いがありました。2つ(2020/07/31 17:06 編集 と 2020/07/31 17:09 編集)のコメントは無視してください。そっと削除するよりはよいと思ったのでコメント追加で失礼します。
Lim-Nic

2020/07/31 08:35

わざわざありがとうございます。 うーん。この後どこを確認すればいいのでしょう。 エラーとなっているSQLを実行する方法も分からずお手上げです。
quickquip

2020/07/31 09:03

純粋に、migrate で正常にテーブルが作られたDBに対してアプリがアクセスしていない、と見るべきなのですね。(同じsettings.pyを使っているにも関わらず!?) DBは https://data.heroku.com/ から Heroku Postgres で作成しているわけですよね。 なにかHerokuに固有なハマりどころな気がしてきました。
Lim-Nic

2020/07/31 09:12

サイト上で確認できるのを初めて知りました。 順序としては、 ① splite3でローカルにプロジェクト作成。 ② Herokuのアカウント作成、アプリの作成。 ③ postgreのインストール、アカウント作成、DBの作成。DB情報をsetting.pyに記入 ④ migrate実施 ⑤ Herokuへデプロイ という内容だったと思います。
quickquip

2020/07/31 09:19

もしかして settings.py のPostgreSQLの設定に 'HOST': 'localhost', と書いている……?
Lim-Nic

2020/07/31 09:28 編集

settings.pyのDBは " 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': '?', 'USER': '?', 'PASSWORD' : '?', 'HOST' : '127.0.0.1', 'PORT' : 5432, }" こう書いています。これってlocalhostと同じになってしまうのでしょうか。?は伏字です。 ALLOWED_HOSTS はHerokuのアプリのアドレス ******.herokuapp.comにしています。 migrate auth は何度も実行を確認したつもりなのですが・・・ 同じ内容だと表示が帰ってきてしまいます。 実行するタイミングが違うのでしょうか。 一度削除するというのは、HerokuのアプリとpostgreのDBを削除してやり直すということですよね。
Lim-Nic

2020/07/31 11:50 編集

Herokuアプリ・postgresDBを削除して再度設定してみましたが 同様のエラーでした。 migrateはauthから初めて、その後通常のmigrateを行いました。 Operations to perform: Apply all migrations: auth Running migrations: Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying auth.0008_alter_user_username_max_length... OK Applying auth.0009_alter_user_last_name_max_length... OK Applying auth.0010_alter_group_name_max_length... OK Applying auth.0011_update_proxy_permissions... OK サイト先の方は、migrate時にエラーが出ていますが 私はアクセスしてDBを参照した時に表示されるので、少し違うのかなと感じています。 少なくともmigrate時にエラーが出ないということは、その時点では参照できていることになりますよね。 デプロイしたことによって本来コピーされる内容が送られていなかったり、heroku上の環境が開発環境と異なる状態で何かが邪魔をして参照先に到着できていないということなのかと、なぜなのかはさっぱりなのですが・・・。
Lim-Nic

2020/08/02 14:15

これはもう解決できそうにないでしょうか・・・。 別のCloudサービスでのデプロイを検討したほうが良いですよね。
quickquip

2020/08/02 15:41

まさかと思っていた(けれどもHerokuを使ったことが実際には一度もないので判断しかねていた)のですが、アプリを起動しているdynoに対して、PostgreSQLをインストールしてデータベースを作っているのでしょうか?
Lim-Nic

2020/08/03 08:30

インストールする作業は開発環境でしかやっていないつもりです。 インストールすることを指定しているのは asgiref==3.2.3 beautifulsoup4==4.9.1 cycler==0.10.0 dj-database-url==0.5.0 Django==3.0.3 django-bootstrap4==2.1.1 django-heroku==0.3.1 gunicorn==20.0.4 kiwisolver==1.1.0 matplotlib==3.2.0 numpy==1.18.1 Pillow==7.2.0 psycopg2==2.8.5 pyparsing==2.4.6 python-dateutil==2.8.1 pytz==2019.3 six==1.14.0 soupsieve==2.0.1 sqlparse==0.3.0 whitenoise==5.1.0 この内容だけです。その他の特別な作業はしていません。
Lim-Nic

2020/08/03 09:51

動作するようになったので報告します。が、原因は分かっていません。 postgresを一度アンインストールして、再インストール Djangoのプロジェクトも新規を作成して プログラム内容を全てコピー&ペーストしたところ Heroku上でもすんなりと動作するようになってしまいました。 自分で作成した手順書を見ながら行いましたが 実行結果で今までと違う動きをしているとも感じられませんでした。 結果的に動いてくれたのは嬉しいですが、納得できない状態です・・・。
Lim-Nic

2020/08/03 10:18

おそらくですが、自分ではDBを削除してやり直しているつもりでしたが 操作していない場所でDBの情報が残っていたのかもしれません。 それにしても開発環境では動作していて、heroku環境では動作しない。というところは 何がどうなっているのか分かりません。 何かが影響してマイグレーションに失敗していたとざっくりした想像でしか結果が出せないような気がします。
guest

回答3

0

自己解決

PostgreSQL,Django,Pythonの環境を全て再導入したところ
正常に動作するようになりました。

投稿2020/08/05 07:13

Lim-Nic

総合スコア18

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

https://qiita.com/norifumi92/items/4ba835234762289b24d0

https://github.com/steuke/heroku-pgbouncer-django-demo/blob/master/pgbouncer_client_demo/settings.py

https://github.com/heroku/heroku-django-template/blob/6bab126ef9d645f36905cf7cb210b4417d867484/project_name/settings.py#L113

などを見るとdj_database_urlを使うのが一般的なようです。


https://github.com/heroku/heroku-django-template

から始めて

python

1from django.http import HttpResponse 2from helloworld.settings import DATABASES 3 4 5def index(request): 6 return HttpResponse(str(DATABASES['default'])

とするだけの最低限のアプリをデプロイして、settings.pyのDATABASES['default']に何が入っているか確認してみました。

{'NAME': 'd9o********v0p', 'USER': 'ocr********atn', 'PASSWORD': 'fe1614****************************************60c3cd15c9f227d82bb', 'HOST': 'ec2-**-***-**-**.compute-1.amazonaws.com', 'PORT': 5432, 'CONN_MAX_AGE': 600, 'OPTIONS': {'sslmode': 'require'}, 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'ATOMIC_REQUESTS': False, 'AUTOCOMMIT': True, 'TIME_ZONE': None, 'TEST': {'CHARSET': None, 'COLLATION': None, 'NAME': None, 'MIRROR': None}}

と入っていましたよ。(*は伏せ字)

データベースの設定がLOCALHOSTや127.0.0.1を見にいくのがおかしいのです。

アプリに紐付いていているHeroku Postgresで作成したデータベースサーバを見にいかないといけないです。

投稿2020/08/02 15:39

quickquip

総合スコア11027

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Lim-Nic

2020/08/03 09:15

私も今デプロイさせているアプリにその項目を追記して確認してみました。 ``` {'NAME': 'd5**********nt', 'USER': 'pg**********ul', 'PASSWORD': '0e*************ee', 'HOST': 'ec2-**-***-***-**.compute-1.amazonaws.com', 'PORT': 5432, 'CONN_MAX_AGE': 600, 'OPTIONS': {'sslmode': 'require'}, 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'ATOMIC_REQUESTS': False, 'AUTOCOMMIT': True, 'TIME_ZONE': None, 'TEST': {'CHARSET': None, 'COLLATION': None, 'NAME': None, 'MIRROR': None}} ``` settings.pyでは Host:127.0.0.1 にしていますが 結果的にAWS内のDBを参照しているように見えます。
guest

0

開発と運用で異なるDBMSを使用することは、Two Scoops of Djangoという書籍に、よくない習慣であることが書かれています。

開発と運用で同じDMBSを使用していれば、運用環境で下記のようにマイグレーションするだけで済みます。

bash

1python manage.py migrate

PostgreSQLのDBを drop database で削除し、再度作成。
makemigrations ⇒ migrate を行いました。マイグレーションは成功していますが

ここからは、調べたわけでなくマイグレーション動作から想像した意見です。

Djangoは、どのマイグレーションファイルを適用したかを記録しています。
また、モデルが変更されていなければ、makemigrationsコマンドでマイグレーションファイルは作成されません。
DBMSを変更したことがないため、DBMSを変更した場合にマイグレーションファイルが作成されるかを把握しておりません。

よって、データーベースを削除しただけでは、マイグレーションファイルは作成されず、適用もされないと思います。

開発時はモデルの変更が重なったとき、マイグレーションを最初からやり直すことが良くあります。このときは、下記を実行するカスタムコマンドを作成して実行しています。

  • すべてのアプリのマイグレーションファイルを削除
  • データーベースを削除
  • マイグレーションの実行

How to Reset Migrations

投稿2020/08/01 03:34

編集2020/08/01 04:21
hasami

総合スコア1277

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Lim-Nic

2020/08/02 14:13

回答ありがとうございます。 確かに別DB環境を移行するのはリスクがあったかもしれません。 1つ疑問なのですが、開発環境で最初SQLite3を使っていて、settings.pyの設定を変えて Postgresへアクセスするよう変更を行った場合、SQLite3で作業をした情報が引き継がれていることになるのでしょうか?それとも、最初からPostgresでDBを作ったことになるのでしょうか? 知識不足で見当違いな考え方をしているかもしれませんが、今回開発環境でPostgresを使って動作することは確認しているので、DBを変更したことが問題なのかイマイチ納得できないところもあります。
hasami

2020/08/02 22:52

これも想像なのですが・・・。 マイグレーションファイルは中間的なファイルであるため、どのDBMSにも適用できると考えています。 ただし、Djangoは、どのマイグレーションファイルを適用したかを覚えているため、当初のDBに適用した マイグレーションファイルは、変更したDBに適用されないのではないかと。 よって、DBMSを変更したことと、すべてのマイグレーションが変更したDBに適用されていないことが問題だと思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.51%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問