Python - Django

数値、文字、それらをchoices使いながら入力させたところから、次はアップロードボタンを設置してjpeg/png/pdfをテーブルのblob列に入れる。 これができたら、資料とかパンフレットとかを保管できる。 画像はjpegとpngぐらいしか自分では使わないから、jpeg保管で統一。 png画像はjpegに変換して保管。 画像は単に保管するだけでなく、検索結果画面の一覧表示のために80 x 45の縮小画像も作って保管してる。 blob列には、保管効率はあんまりやけど普通の文字列で扱える base64 エンコードを使ってる。 こうすると重たくなることもあるけど、html内にインライン展開して表示できる。 保全策として10MBのアップロード制限している。 実測20Mbps程度のwifi環境でamazonのfireタブレットでも閲覧・登録できる。 格納した文字列に勝手にコードがついてくれて苦労した・・・。 実際の画面の動きと、djangoに書いた内容をメモ。 画面の動き 実際はログインしてから使う資産管理の画面の一部。 ログイン機能 やデータベース(mariadb利用)の 読み書き 、入力画面の 詳細 は別のシリーズでやったので詳細は割愛。 モジュールも大きくなったので 分割 もしてるけど、追加・改善続けたらやっぱりデカくなってくなぁ。 パッケージの状態は、本当の最初の頃はdjango本体以外はこれぐらいしかなかった。 1 2 3 4 5 6 7 8 Django==3.2.7 uwsgi==2.0.19.1 django-markdownx==3.0.1 Markdown==3.3.3 Pillow==7.0.0 PyMySQL==1.0.2 matplotlib==3.4.3 numpy==1.21.2 現在pipでインストールしているモジュールは以下のとおりで、去年の年末まではdjango3、12月頃からdjangoは4に バージョンアップ した。 ...

djangoの4.0ってのが先週に出たらしい。 せめてマイナーバージョンが１つ上がって4.1まで待ちたいけど、メジャーバージョンアップの練習してみたい。 この秋あたりから3.2～3.9と使い始めてきて、冬にバージョン上げてdjangoの記述をどんなふうに変えていくのかやってみた。 元のバージョン djangoはrequirement.txtに必要コンポーネントのバージョンを書いておく。 自分用にパッケージをバージョンアップするためのメモを 最初の頃に作ってある 。 djangoのロケット画面表示をdockerコンテナで表示させてた頃に手動作成したrequirement.txtはこれだけ。 その後もmariaDB接続と円グラフ描く練習のためだけなので内容は少なかった。 1 2 3 4 5 6 Django==3.2.7 uwsgi==2.0.19.1 django-markdownx==3.0.1 Markdown==3.3.3 Pillow==7.0.0 PyMySQL バージョン上げる 業務として真面目にやるなら、先にリリースノートを読むべき。 Django 4.0 release notes | Django ドキュメント | Django docs.djangoproject.com でも今は業務じゃなくてプライベートでの練習やし、ドキュメント読むの面倒やし、読まずに問題に当たったとしてもその解決過程を楽しみたいし。 失敗したら、/code/appのフォルダをdockerの永続化領域としてtar.gzで保管してるから丸ごと戻す。 問題が出たらリリースノート読むってことで、いきなりpip実行した。 エコー結果は長いし、アップグレードは「success」ってのしかチェックしないので割愛。 以下、実際にやったこと。 アップデート必要なパッケージ一覧確認(pip3 list -o)で目視確認 エラーが出ないか目視しつつパッケージのアップグレード(pip3 install –upgrade) パッケージの依存関係チェック(pip3 check)して問題出ないか確認 パッケージの書き出し(pip3 freeze)してバージョン記述の確定内容をrequirement.txtに残す ここまででrequirement.txtはこうなった。 えらい行数増えてるなぁ。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 asgiref==3.4.1 backports.zoneinfo==0.2.1 cycler==0.11.0 Django==4.0 django-markdownx==3.0.1 fonttools==4.28.4 importlib-metadata==4.9.0 kiwisolver==1.3.2 Markdown==3.3.6 matplotlib==3.5.1 numpy==1.21.4 packaging==21.3 Pillow==8.4.0 PyMySQL==1.0.2 pyparsing==3.0.6 python-dateutil==2.8.2 pytz==2021.3 six==1.16.0 sqlparse==0.4.2 supervisor==4.2.2 uWSGI==2.0.20 zipp==3.6.0 バージョン上げたときのdjango処理内の対処 バージョン上げたんやからmigrateする。 ...

前回まで で、データベースに入っている文字や数字が、きちっと画面で登録・更新できるのかそれぞれ試した。 今回の、日付でjavascript使うとこと、decimalのリストボックス化は悩んだな。 数字 普通はinteger使う。パーセンテージとかレートみたいなのを扱いたいときは、floatじゃなくdecimalを使う。 floatは誤差が出そうやから使わない。 学術に使うときはfloatのほうがいいのかもしれないけど、お金を扱う場合に誤差が出たら困る。 個数とか通し番号はmodelsの中で「IntegerField」で定義。 重量とかだったら「DecimalField」で定義。 1 2 3 4 5 6 7 kazu = models.IntegerField(verbose_name='数量',db_column='Kazu', blank=True, null=True) # Field name made lowercase. def __str__(self): return self.kazu weight = models.DecimalField(verbose_name='重量-kg',max_digits=8, decimal_places=4, blank=True, null=True) def __str__(self): return self.weight 自分はdjango起点で考えているわけじゃなく、mariadbに業務データがありき、それをdjangoにinspectさせてmodelsを自動生成させたので、型について深く考えて選んだわけじゃない。 むしろmariadbでどう入れるか考えたものをdjangoに解釈してもらった。 データを先に考えて作る。 データベースの型との対照表を書いておられる方がいてわかりやすかった。 mariadbはmysqlのところ参照させてもらった。 作者さんありがとう。 Django モデルフィールド：データベースフィールド 型対応表 #Python - Qiita qiita.com 数字の入力項目は、入力フィールドに自動で上下ボタンがつく。 ...

前回まで でデータベースにある業務データを読み書きできるようになった。 ここまで来るとソースも大きくなりがちで、viewsとmodelsがデカくなってくる。 自分の好みやけど、できるだけ１つの定義とか機能は１００行ぐらいでおさまってほしい。 modelはデータベースの列の数に依存やから、まぁしゃあないか。 できれば分割できないかって思ってたら、あります、できます、その作成メモ。 分割方法をまとめておられる方がおられた。 作者さんありがとう。 formsのことは書いてなかったけど、だいたい同じ要領でできる。 django開発で肥大化したview.py を複数ファイルに分割する方法 #Python - Qiita qiita.com Djangoでモジュールを複数ファイルで構成する #Python - Qiita qiita.com 分割対象はこのへん ⭐️の箇所を更新。まずはviewsを分割し、urls.pyを書き換えていく。 次にmodelsを分割して__init__.pyにmodel定義の一覧みたいなのを追記。 けっこうあっさりできてしまう。 今は小さいけど、formsも割る準備やっちゃう。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 /code/app |--gvisDjango3 | （円グラフ等、ステータス表示のための別プログラムのため省略） |--gvisWebApp | |--__init__.py | |--__pycache__ | |--admin.py | |--apps.py | |--forms.py ⭐️4 | |--migrations | |--models.py ⭐️3 | |--tests.py | |--urls.py ⭐️2 | |--views.py ⭐️1 | |--templates/gvisWebApp | | （ログインとcrudのhtmlのため省略） |--manage.py |--requirements.txt |--templates | |--gvisDjango3 | | （円グラフ等、ステータス表示のための別htmlのため省略） |--website | | （円グラフ等、ステータス表示のための別htmlのため省略） viewsの分割 さっきのツリーにあるviewsを分割。 ...

ログインしないとページが見えないようなアプリケーションを構成し、データベースにある業務データを読み書きできるようにする。 1.dockerコンテナ準備onSSL 、 2.pip利用とhelloWorldとdb接続 、 3.グラフ表示練習 では環境を作り、処理を作っていくための習作みたいなものまで作れた。 その後 4.ログイン画面 もできた。 次はcrudを目指す。djangoでmariadbを読み書き削除させる。ListView,DetailView,CreateView,DeleteView,UpdateViewをそれぞれ使う。phpで作った全機能はまだ無理で部分的やけど、いくらか使えるようになったのでその作成メモ。 いろんなページ参照させてもらいました。 作者のみなさんありがとう。 【準備】crudするためのデータベース データの読み書き処理ではテストするときにデータをいくらか壊していく。 アプリケーションが無茶苦茶しても、データはいつでも元に戻せるようにしとかないとね。 自分の場合、オリジナルデータはgoogle cloudのlinuxで動かしているmariadbコンテナにあるから、そのコンテナの永続化領域をそのまま持ってきてローカルのmariadbのコンテナにアタッチして使ってる。 djangoの管理画面が起動できるようにしたときに作られるテーブルは１０個。「auth_」で始まるものと「django_」で始まるものがそれ。 これを丸々mysqldumpってコマンドでバックアップ取っておき、データベース名を書き換えて「nariDB_Django」のスキーマへリストアし、「GVIS_」で始まる業務テーブルをcreateしておく。 nariDB_1stが業務テーブルだから、nariDB_Djangoに向かってa5sqlの「スキーマ間のデータ転送」を使ってデータを流し込めばいつでもデータがオリジナルと同じになる。 a5sql の作者さんありがとう。 このソフトウェアとても優秀。使ってないけど、なぜかテーブル定義書まで出せる。しかもけっこうキレイに出る。ポータブル版としても動くのでめっちゃ便利。 以前はoracleやsqlserverも扱うことがあったからnavicatを使ってたけど、今はmariadbだけなのでa5sqlで足りる。 navicat は有償で高価だけど、データの移行はめっちゃ楽。それはまた別の機会に。 オリジナルデータにはblobが入っているテーブルがあって、その中にjpegやpdfが入っている。だからコミットは１０００件ずつじゃなく、１００件ずつでのっそり動かす。トータル4GB程度なので、５分ぐらいで転送終わる。 サラッと書いてるけどコンテナで扱うからちょっと工夫が必要。 DBはまた別のページで書くか。 【準備】自前のcss 自前というか、以前に人にお願いして作ってもらったものを更新しながら利用。タブレットとかiphoneで見るためのおまじないのためでもある。 php版ではやってないけど、djangoではページネーションに挑戦。検索結果を表示するとき、たとえば１ページ２０個レコード表示させておき、その他レコードは別ページでってことで。 ページネーションってこういう感じのやつ。 これをやるにはcss使う。ググるとbootstrapを使うのが多い。自分は普通のページネーション装飾を参考にさせてもらい、ベース色を変更してcssに追記した。 実際はまだまだ作りこんでいくので、ページネーションする箇所は別htmlで切り出して使うようにした。 【結論】実際の動き 見た目の動きはこうなる。以下作った順。 ログイン 前回作った画面でログインする。イントラのサイトでオレオレ証明書使ってsslでつながってくれる。 メニュー画面 未作成箇所あるけど、今回は真ん中のボタン「（作成中）資産一覧」ってとこ。他にも帳簿入力画面とか作っていくんだけど、crudの基本を資産登録機能で作っておいた。 一覧表示 ページネーションで最終ページ表示させたところ。 この表示ができるようになるのは苦しんだ。djangoにはページ表示のために関数版とクラス版があることに気づき、関数版で作りかけてたのをクラス版でやり直した。modelsとformsを組み合わせて自動生成してくれるのもなかなか理解しづらかった。 php版で実現していることはそのまま実現できないので、まだまだデザイン変えてかないと。 最後の３件はテストで作成したレコード。 詳細表示 今はのっぺりしてるけど、この機能を最後まで作ったらmariadbのテーブルのblob列に入ってる写真やマニュアルを閲覧するのに使うかな。 新規作成 テストデータ入れて試してるところ。作ってる途中はフォームの扱いに苦しんだな。 削除 確認メッセージは必要やね。このあたりで新規作成と更新画面の両方に確認メッセージと、完了メッセージの表示させ方考え始めた。 更新 本当はこの画面の「Seq2」は入力項目じゃなくて自動発番させたい。レコードの中から最大値を得てインクリメントしたものを設定すればたぶんできるけど、今はこのままでいいか。 更新だけじゃなく、新規作成もだけどjavascript使って確認メッセージ出るようにした。バリデーションとか入力画面を作ってくれるなら、このへんもdjangoでやってくれたらいいのに・・・。 djangoの修正対象はけっこうある 今回もある程度できた後で、gitの差分を見ながら作った箇所書いてるのな。 ...