Python - Django

djangoでblob列を含むレコードを作成・更新・参照・削除することができるようになった。 自分特有の blob操作 もできるようになった。 ただ、これだけでは自分にとって使える処理とは言えない。 普段は一度入力した内容をコピーして再作成することのほうが多い。 １から入力するんじゃなく、既存レコードをコピーして更新しながら作る。 そのほうが楽やし。 今回はレコードをコピーする処理を作ったのでそのメモ。 結論 実際の作りはこうなった。 月間作業予定の一覧を年月単位で存在させてて、優先順位を番号として付けてある。 listviewを使って一覧表示させたレコードに「行コピー」ってボタンを作って、そのレコードをコピーし、ボタンを押すとそれ以降のレコードの優先順位を＋１する。 例えばこういうレコードがあって3列目にあるコピーボタンを押すと、 こうなる。 ４列目に優先順位「２７」ってあるレコードがコピーされて「２８」ができてる。 ここで「２７」からさらにコピーすると、「２７」と「２８」は「２８」と「２９」になって、元の２７を新規レコードとして保管する。 右端の３列にガッキーのjpeg、五線譜のpdfの１ページ目をjpeg変換したもの、ガッキーの別のjpegがちゃんと入ってコピーされている。 しっかしガッキーかわいい。 格納したファイルと性能 jpegは100KB程度やけど、pdfはムーンライトソナタの譜面で16ページ、7.5MB程度ある。 それをbase64でエンコードして保管するから、容量は1.5倍程度として１レコードはたぶん10MB強。 それでもdjango的には１秒もかからず処理してくれている。 ２０件ある先頭レコードでコピーしても同じやった。 数百件とか数千件だと時間かかるのかもしれないけど、ここではこれで十分。 dockerコンテナでもこれぐらい動いてくれるんやなぁ。 レコードの構成 jpegとpdfは実表示用データ(longblob)だけでなく、一覧表示するときのための縮小版(mediumblob)を持ってる。１レコードに３つの添付ができるように、同じようなフィールドが３つずつある。 mariaDB上の定義 前回のblob操作は在庫のテーブル使ってたけど、今回は活動テーブル。 BLOBって名前で始まる列の定義は他のテーブルも完全に同じ。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 CREATE TABLE `GVIS_work` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id', `workPeriod` datetime DEFAULT NULL COMMENT '業務期間-開始日', `workShubetsu` char(4) DEFAULT NULL COMMENT '作業種別', `workPriority` int(10) DEFAULT NULL COMMENT '優先順位', `Category1` varchar(100) DEFAULT NULL COMMENT 'カテゴリ1', `Category2` varchar(100) DEFAULT NULL COMMENT 'カテゴリ2', `Tehai` varchar(10000) DEFAULT NULL COMMENT '手配方法・名称・機種', `Kazu` decimal(12,4) DEFAULT 0.0000 COMMENT '数量', `Tnk` decimal(12,4) DEFAULT 0.0000 COMMENT '単価', `Kng` decimal(12,4) DEFAULT 0.0000 COMMENT '金額', `WorkTime` decimal(12,4) DEFAULT NULL COMMENT '作業時間', `Biko` varchar(100) DEFAULT NULL COMMENT '備考', `BLOB_data1` longblob DEFAULT NULL COMMENT 'BLOBデータ1', `BLOB_data2` longblob DEFAULT NULL COMMENT 'BLOBデータ2', `BLOB_data3` longblob DEFAULT NULL COMMENT 'BLOBデータ3', `BLOB_extent1` varchar(100) DEFAULT NULL COMMENT '添付mime1', `BLOB_extent2` varchar(100) DEFAULT NULL COMMENT '添付mime2', `BLOB_extent3` varchar(100) DEFAULT NULL COMMENT '添付mime3', `BLOB_medium1` mediumblob DEFAULT NULL COMMENT '添付-埋め込み画像用1', `BLOB_medium2` mediumblob DEFAULT NULL COMMENT '添付-埋め込み画像用2', `BLOB_medium3` mediumblob DEFAULT NULL COMMENT '添付-埋め込み画像用3', `ins_date` datetime DEFAULT NULL COMMENT 'データ作成日', `ins_user` varchar(100) DEFAULT NULL COMMENT 'データ作成ユーザ', `upd_date` datetime DEFAULT NULL COMMENT 'データ更新日', `upd_user` varchar(100) DEFAULT NULL COMMENT 'データ更新ユーザ', PRIMARY KEY (`id`), KEY `IDX_work` (`workPeriod`,`workShubetsu`,`workPriority`,`Category1`,`Category2`,`Tehai`(255)) ) ENGINE=InnoDB AUTO_INCREMENT=1502 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC django内のmodels.pyの定義 blob列はdjangoではTextFieldになる。 ...

djangoで作っている処理をローカルlinuxで開発し、Google Cloudの中に反映させる。 前回 にGoogle Cloudの本番環境を作った。 作り終わった直後、できてない件があるなって気づいた。 ローカル開発環境はcssで画面を緑色系にしてるのを、本番は青色にしたい DBは開発用のDBインスタンスを使ってるので切り替えたい ヘッダの中に「ログアウト」のリンクがあるのが使えない これはGoogle Cloudとローカルlinuxでそれぞれtemplatesに置くhtmlやsettings.pyを用意しておき、コンテナを起動するときに切り替えればいい。 そこで、dockerのコンテナをdocker-composeで起動するとき、その直前にファイルコピーするようにスクリプトを書き換えた。 結果 ローカルlinuxでこう見えてるのが、 こうなる。 想定しているファイルを用意して上書きコピーしたら、すんなりできた。 データベースも複数あるのを切り替えて使えるようになった。 開発環境では好き放題データベース書き換えてテストできるのは必須やし。 以下、変更実施スクリプト作成内容。 前提 ローカルlinuxもGoogle Cloudも、docker-compose.ymlを複数使ってる。 webアプリ、mariadb、gitlab、ubuntu20のrdp環境を起動して帳簿入力 oracle起動してちょっとSQL試したいとか、検証するための環境を起動 centos7、centos8、ubuntu20など複数のOSフレーバーへsshできるようにし、OS利用してdockerfile作るための環境を起動 それぞれ永続化領域を持たせていて、「今日はcentosの検証作業」とか「今日は帳簿入力」とか使い分けてる。 dockerだと、サーバの役割をホイホイ変えられるから、必要なサービスを必要なだけ起動すればいい。 コンテナ起動のための基礎になるスクリプトはこう書いている。 1 2 3 4 5 6 7 8 DOCKER_ROOT=/Docker cd ${DOCKER_ROOT} ### cp -p docker-compose-GVISweb.yml docker-compose.yml ### cp -p docker-compose-DBMS.yml docker-compose.yml ### cp -p docker-compose-Client.yml docker-compose.yml docker-compose up -d cpしている箇所のうち、どれか１つだけコメント箇所を外して使ってる。 ...

資産や取引の登録・更新画面がdjangoでできつつある。 ようやっとphpから脱却できるメドがついた。 あとは作っていくだけ。 ローカルでの開発環境は使えているので、次は本番環境を用意する。 開発してテスト終わったら、git管理のソースをgoogle cloudの中のサーバで動かせるようにする。 コンテナ作って永続化領域に作ったソースを置き、sslのコンテナ経由で公開させてブラウザで使う。 今回はその環境作成メモ。 ローカルlinuxはubuntu20が動いていて、google cloudからコピーしたphp/mariadbのコンテナが動いている。他にも練習用のコンテナが一時的に動いてる。 google cloudにはローカルlinuxと同じubuntu20が動いていて、その中にphp/mariadb/gitlab/rdpのコンテナが動いている。 ここにdjangoとsslのコンテナを追加して、rdpのコンテナからssl経由でdjangoのコンテナをブラウザ経由で使う。 djangoのソースはgit管理していて、ローカルlinuxで開発した結果をgoogle cloud内に持って行って永続化領域にコピーして使う。 できた結果をgoogle cloudのrdpコンテナに接続して使ったらこんな感じ。 どっかで悩むかと思ったら、スンナリできた。 docker様ありがたや、ありがたや。 準備 djangoの管理テーブルを丸ごと開発環境からコピーし、djangoとssl公開用のコンテナを作って、google cloud内のrdp環境にあるブラウザで表示できるようにする。 ホンマにちゃんと動き続けられるのか心配やけど、やりながら考えていく。 データベースの準備 データベースはmariadb利用。 開発用DBはnariDB_Djangoって名前。nariDB_1stっていう本番データベースのコピーも含んでローカルlinuxのnafslinux.intra.gavann-it.comで持たせてる。 一番上にあるgcp-gvis-docker-mariadbがgoogle cloudにある本番データベースで、nariDB_1stって名前で持たせているので、ここにdjango用の管理テーブルを作る。 いきなり作って失敗したらツラいので、ローカルlinuxにある同じnariDB_1stで練習してからgoogle cloudの本番データベースに対して実施する。 この作業では、作業で失敗しないようにコピー元のデータベースは読み込み専用で開くこと、コピー先のデータベースはmysqldumpで事前にバックアップを取ってあることに必ず留意した。 djangoが管理している対象テーブルの特定 自分の業務テーブルは１３個。 GVISで始まる名前のテーブルで、資産管理とか取引とかがblobまじりのテーブルに入ってる。 djangoはmigrateとかして自動生成され、専用のテーブルを10個使ってる。 auth_xxxとdjango_xxxって名前のがそれ。 ホンマa5sqlあると助かる。作者さんありがとう。 対象テーブルのcreate 定義はローカル開発環境のものを10個そのままa5sqlで参照してそのまま使う。 よく見ると外部キーみたいなのがついてる。 たとえばauth_permissionのテーブルにcontent_type_idって列があって、FOREIGN KEYの箇所からdjango_content_typeってテーブルのidって列を参照してる。 1 2 3 4 5 6 7 8 9 10 CREATE TABLE `auth_permission` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL, `content_type_id` int(11) NOT NULL, `codename` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `auth_permission_content_type_id_codename_01ab375a_uniq` (`content_type_id`,`codename`), CONSTRAINT `auth_permission_content_type_id_2f476e4b_fk_django_co` FOREIGN KEY (`content_type_id`) REFERENCES `django_content_type` (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=141 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ; こういうときは、FOREIGN KEYの記述で参照される側から順番にcreate tableしてデータを入れて行かないと、うまくレコードが入っていかない。 ...

vscodeを使っていると、左端に拡張機能があってgit操作とかマークダウンのプレビューとか気軽に使える。 しかもwindows/mac/linuxでほぼ同じような操作と利用感が得られる。 さすがms。 めっちゃ便利。 visual basic2.0で初めてソース書いた時に同じような感動があったな。 djangoって拡張機能を入れておくとシンタックスを補正してくれたり、作ったviews/models/formsなんかを入力候補に表示してくれて、選ぶと勝手にコードを補ってくれる。 書き方の記憶が曖昧だったり、こう書けば処理として行けるかなって思ったとき、試し入力するとその候補を見せてくれるのはとても助かる。 ついでにgit関連の拡張機能も入れておくと、コミットとプッシュをいちいちコマンドラインで入力しなくていい。 何か問題出た時だけ手入力でgit操作することもあるけど、あまりに楽すぎて手入力のやり方忘れた。手でやるのはgit cloneぐらいか。 自分のdjango環境はlinuxサーバにあるdockerコンテナをsslコンテナを通して表示させている。 今回はこのコンテナで使うdjangoソースをmacで編集するときのメモ。 環境 googleクラウドを本番環境に見立てて使ってる。 4コア16GBメモリにhdd300GB。ssdはそれほど性能出ないのに単価高いからhddでいい。 容量は多いほどいいけど300GBで足りるし、消費量じゃなくて確保量で課金やから、300GBならだいたい1200円ぐらい。そこにcpuやらメモリ使用が足されてく。 xrdpコンテナはubuntu20のXwindowが使える。 ２年ぐらい前までcentos7のxrdpコンテナを作って使ってたけど、centos8になったらめっちゃ不安定になったので、dockerhubでたまたま見つけたubuntuのxrdpに変えた。 ローカルＰＣから rdp接続 して、ブラウザでphpアプリケーション使ってる。 gitlabの管理はxrdpコンテナに入れたvscodeとブラウザでやってる。 xrdpの中で全部済ませることで、下りパケット料金も抑えられる。 アプリケーションはgit cloneしてzipしておき、データベースはエクスポートした結果をzipで固めて、google driveにバックアップ入れておく。 ローカルlinuxへは、cyberduckとか使ってこのバックアップを取りに行き、展開用のバッチ処理をスクリプト化して作っておいて同じものを展開する。 google cloudへローカルの内容を反映させるときも同じ感じで使う。 googleクラウドの中は異様にネットが速くて、1500Mbpsぐらい速度が出るから、合計10GBぐらいのzipでも10分もあればバックアップ終わる。 ７割がhddの費用で、週１回ぐらい使って、google cloud月額2000円未満。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 +------------------------------+ |google | | +--------------------------+ | | | ubuntu20 | | | | +---------------------+ | | | | | docker | | | | | | +----------------+ | | | | | | | mariadb | | | | | | | +----------------+ | | | | | | | | | | | | +----------------+ | | | | | | | php | | | | | | | +----------------+ | | | | | | | | | | | | +----------------+ | | | | | | | gitlab | | | |⭐️ここでソース管理 | | | +----------------+ | | | | | | | | | | | | +----------------+ | | | | | | | xrdp | | | |⭐️ここでlinuxのgui使えるのでvscodeやブラウザ使う | | | +----------------+ | | | | | +---------------------+ | | | +--------------------------+ | +------------------------------+ ローカルlinuxサーバはgoogleクラウドのコピーみたいなもので、djangoへのリプレース開発を今はやってる。 ...

ログって業務ではよく見るけど、個人的にはあまり見ない。 何かエラーが出た時とか、操作履歴を調べたいときとか。 テキストファイルに吐き出すとgrepできるから便利ってのもあるけど、自分はデータベースに書き出してる。 勝手に圧縮してくれるし、古いログを消したいなら書き込み日付で削除のsql発行すれば一発で終わるし。 できるだけ楽をしたいなぁって思う。 あと、テーブルを使う理由は新しい順に表示させてほしいから。 テキスト表示だと、新しい書き込みは下に追加されていく。 sortかcatの逆のtacでできるけど・・・。 linuxのlogrotate設定は、bashのスクリプト使って日次バックアップの結果ログとかで使ってはいるけど、ローテート設定面倒なのであまり好かない。 世代とかサイズとか指定してく必要がある。 アプリケーションとしては、dockerコンテナで、しかもsslをnginxを通じてdjangoのコンテナを使うとログ出力がどうなるのかやってみた。 mariadbのテーブル定義 ログは、いつ、誰が、何をした、みたいなことが残ればいい。 必要なら発行したsqlとかも入れればいいけど、そこまで必要なのは業務利用の場合かなぁ。 7年ほどphpで使ってきた仕組みをdjangoで書き換えて踏襲するので、データベースのログ保管の定義は変えない。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 CREATE TABLE `GVIS_log` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id', `logPeriod` datetime DEFAULT NULL COMMENT 'ログ年月日時分秒', `logShubetsu` char(10) DEFAULT NULL COMMENT 'ログ種別', `clientIP` char(15) DEFAULT '' COMMENT 'クライアントIP', `userID` char(32) DEFAULT '' COMMENT 'ユーザID', `Sousa` varchar(100) DEFAULT '' COMMENT '操作', `Message` varchar(10000) DEFAULT NULL COMMENT 'ログメッセージ', `browser` varchar(100) DEFAULT '' COMMENT '操作', `ins_date` datetime DEFAULT NULL COMMENT 'データ作成日', `ins_user` varchar(100) DEFAULT NULL COMMENT 'データ作成ユーザ', PRIMARY KEY (`id`), KEY `GVIS_log_idx` (`logPeriod`,`userID`,`Sousa`,`Message`(255),`browser`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=66928 DEFAULT CHARSET=utf8 django用って言うと、djangoのためにid列を追加したっけ。 テーブル定義にはオートナンバのidがつかないとdjangoは処理出来ないっていうし。 ...