この接続ではプライバシーが保護できません。

ShowCase.siteの証明書にLet’s Encryptを使用しているのだが、90日を過ぎた時点で「この接続ではプライバシーが保護できません。」(NET:ERR_CERT_DATE_INVALID)と表示され、サイトが開けない状態に。
証明書発行の更新はcrontabで自動更新しているので、問題ないはずなのに。
>sudo certbot renew
で手動更新してもかわらず。
試行錯誤後、nginxをリスタートしたら、無事サイトが開けた。
>sudo systemctl restart nginx
crontabは
00 09 1 * * /usr/bin/certbot renew -q –renew-hook “/bin/systemctl reload nginx”
reloadが間違ってたってことか...

ValueError: Related model ” cannot be resolved

クライアント環境で新たに追加したテーブルを既存テーブルの項目として外部キーを指定して追加した後、デプロイ先のクラウド環境へ同様の作業を行おうとして、躓いたので備忘録。
新たに追加したテーブルを既存のテーブルの項目として追加し、外部キーとして追加した。
作業手順としては、
・新しいテーブルを作成
・新しいテーブルにデータを追加
・既存テーブルの項目に新しいテーブルの外部キーを追加
ところが、デプロイ先ではこの手順で作業しようとすると、
>python manage.py makemigrations
を実行した時点で、
ValueError: The field [既存テーブルの項目名] was declared with a lazy reference to ‘[アプリ名.追加テーブル名]’, but app ‘[アプリ名]’ doesn’t provide model ‘追加テーブル名’.
と怒られた。
そこで、どうやら、手で追加したテーブルがmigrationとして認識されていないなと思い、手作業で追加したテーブルをdropして、magrationsフォルダの下の最新のmigration実行用ファイル(000n_auto_YYYYMMDD-HHFF.py)の追加したテーブル部分だけを残してそのほかを削除し、
>python manage.py migrate
を実行して、データを管理画面から手で追加。
再度、最新のファイルの内容を既存テーブルの項目(migrations.Addfield(…))だけ残して実行すると、今度は
ValueError: Related model ‘[アプリ名.追加テーブル名]’ cannot be resolved
と怒られた。
結論から言うと、migration実行用ファイル(000n_auto_YYYYMMDD-HHFF.py)内の
dependencies = [
(‘[アプリ名]’, ‘000n_auto_YYYYMMDD_HHFF’),
]
のアンダーライン部分をそのまま実行したため、migration処理が直前の処理を認識できず、エラーを吐いていたと思われる。
新たにmigration実行用ファイルを追加して、そこに既存テーブルへの外部キーを追加する処理部分を記載し、dependenciesに先ほどテーブル作成したファイル名(.pyを除く)を指定して
>python manage.py migrate
を実行したら、無事作成できた。
当然と言えば、当然だけれど、エラーだけ見るとさっぱりわからないし、ググっても同じような事例は見当たらなかった。
わかったことは、migrationという仕組みが、実テーブルだけではなく、前回実行履歴を参照して実行されるということと、外部キー参照している項目を追加する場合、元のテーブルは作成しているだけではなく、実データも入力していないと、外部キーとして項目追加するとき、デフォルト設定した値の参照先がないというエラーとなり、migrateできなくなる。
この場合は、上記のように、最初に参照先のテーブルを作成するようmigration実行用ファイルを修正して、migarateし、データをinsert後、外部キーの項目追加をおこなう必要がある。
その時参照される履歴とは、[アプリ名]’, ‘000n_auto_YYYYMMDD_HHFF.pyであり、000n_auto_YYYYMMDD_HHFF.cpython-99.pycということだ。
このことを知っていれば、同エラーが発生した場合、全テーブルをdropして、maigarationsフォルダ配下のファイルを__init__.py以外すべて削除して再度作成しなおしたらうまくいったなどという解決策を平然とのせている回答例よりはましな解決策がみつかるのではないか?

migrateでテーブルが追加されない

Djangoで新規に追加したテーブルがmakemigrationsで認識されない現象が発生したのでググって解決しようとして、うまくいかなかったので備忘録。
まず最初に躓いたのが、AttributeError: ‘NoneType’ object has no attribute ‘is_relation’というわけのわからないエラー。
これはクライアント側でテストしたソースをgitでデプロイ環境へアップした際に発生。
この現象はdjango-reset-maigrationsをインストールし、INSTALLED_APPSに’reset_migrations’,を追加して、python manage.py reset_migrations appを実行して解決しましたが、次にテーブルを追加した後に同じようにデプロイした後、makemigrationsすると何も更新するものないよと言われました。
それで、デプロイ先のテーブルを覗くとやはり、該当するテーブルが存在しないので、ググって、app/migratesの下の__pycache__と、__init__.py以外を削除すればいいのかと思いおもいきり削除した結果、django.db.utils.ProgrammingError: relation “app_xxxxxxxxxx” already existsというのが出るようになってしまいました。
今思えば当然のことですが、仕方ないので、データベースから、”app_*”をdrop。
ようやく、makemaigrationsからmigrateまで、無事実行できました。
本番ではデータのバックアップ/戻しなど手間のかかる作業となりそうです。

一つのアプリだけテーブル削除して、やり直したければ(通常のmigrateがスルーしてしまう場合)以下の方法が有効のようです。
python manage.py migrate –fake app_xxxxxxxxxx zero
を実行する

python manage.py showmigrationsで確認

app_xxxxxxxxxx
[ ] 0001_initial

※スルーする場合だいたい、[X]0001_initialとなっているはずなので、XがはずれていればOK

python manage.py migrate
を実行する。


Djangoで直接SQLを実行した値をTemplateに表示する

例えば、viewsで直接SQLを実行した場合、結果を表示するにはどうするのでしょうか?
from django.db import connection
views側
SQL = ‘SELECT A.id,B.name,C.dept_id ‘ \
            ‘ FROM exhibitinfo A LEFT JOIN dapartment B’ \
‘ ON A.dept_id = B.id AND B.syain_id = {}’  \
            ‘ INNER JOIN customuser C’ \
‘ ON A.user_id = C.id’ \
            ‘ WHERE A.is_display=True ORDER BY A.id DESC;’.format(request.user.id)
with connection.cursor() as cursor:
  cursor.execute(SQL)
            exhibit = cursor.fetchall()
for history in connection.queries: 
           logger.info(‘****** history:’ + str(history))
context = {
        ‘exhibit’: exhibit, 
}


template側
{% for item in exhibit %}
<div>{{ item.0}}</div> ← id
<div>{{ item.1}}</div> ←name
<div>{{ item.2}}</div> ←dept_id
{% endfor %}

となります。
例が悪くすみません。
(というか、躓きそうなところをできるだけ網羅しました。)

allauthのLoginカスタマイズ

all-authをインストールした仮想環境(以下の場合”venv”)のall-authのテンプレートをすべて、自作アプリのテンプレートフォルダにコピーします。
venv/lib/python3.x/site-packages/allauth/templates/account
→ templates/allauth/account

次に、settings.pyの”TEMPLATES”に以下の☆を加えます。
TEMPLATES = [
    {
        ‘BACKEND’: ‘django.template.backends.django.DjangoTemplates’,
        ‘DIRS’: [
            os.path.join(BASE_DIR, ‘templates’, ‘allauth’),   ☆追加
            os.path.join(BASE_DIR, ‘templates’),
        ],
  …
あとは、templates/allauth/account配下のlogin.htmlを修正すればカスタマイズ可能です。