読者です 読者をやめる 読者になる 読者になる

django-debug-toolbar は便利(とVirtualboxのVMで表示にハマった件について)

class base view がわからない

存在は前から知っていたけど、まあ別にいいやって思ってて使ってなかった。でも久々の Django でいろいろ忘れてるし、あと 1.5 を使うのはいいけど class base view が mixin しまくってて拡張や仕様変更や保守に強そうというのはいいんだが単に便利セットが増えたという話だった、やっぱり正直どうつかえばどう動くのかよくわからない。資料はあるが実感がわかない。

そういうことでとりあえず発行されている SQL がみたかった。前も ForeignKeyとfilterのメモ - atas でみてたことはあったけどやっぱりだるいのでいい感じのデバッガをいれた。

前提

django-generate-scaffoldをさわってみたメモ - brainstorm
modocache/django-generate-scaffold · GitHub
を参考に導入した。ただテンプレートタグが url の部分辺りで 1.4 と 1.5 で互換性がないので 1.5 対応修正をしてくれたバージョンを使用した
drillbits/django-generate-scaffold · GitHub

# github からのインストール
# egg の部分は任意の名前でいいっぽいけど、いまはよくわかっていない
pip install -e git+https://github.com/drillbits/django-generate-scaffold.git#egg=moge
# 導入した virtualenv 内で git のブランチを切り替える
git checkout django-1.5-support

導入

django-debug-toolbar便利 - 偏った言語信者の垂れ流し

pip install django-debug-toolbar

django-debug-toolbar 0.9.4 : Python Package Index の公式を参考にして、settings.py に以下の項目を追記する。簡単だけどコピペできるくらいのレベルまで落としておく。

INSTALLED_APPS += (
    # これを追加
    'debug_toolbar',
)
# 許可IP
# 開発なのでローカル
INTERNAL_IPS = ('127.0.0.1',)
MIDDLEWARE_CLASSES += (
    # これを追加
    'debug_toolbar.middleware.DebugToolbarMiddleware',
)

とりあえずこれで動く。PyPi にあるドキュメントだとオプションがあるけど、とりあえずデフォルトだと全部有効っぽいのでそのままにしてる。

追記 ローカルの Virtualbox の VM でも表示させる

クライアントは Mac で、開発は Ubuntu Server でやっている。で、そのときパネルが表示されなかった。ローカルで試すと大丈夫ということは、 INTERNAL_IPS の許可 IP あたりの設定という目星はついた。が、クライアントの IP である 192.168.xxx.xxx を許可してもうまく表示できなかった。

探した結果、やはり StakOverFlow にいきついた
python - django-debug-toolbar not showing up - Stack Overflow
ここでも「Debug=True で許可 IP はサーバーじゃなくてクライアントだよ」とあるけど、それでもだめだったとき「request.META["REMOTE_ADDR"]みろ」ってのが助かった。

class base view なのでてきとうに TemplateView とかだと request オブジェクトを拾ってくれないので、てきとうに get メソッドの中でブレークさせた

class MyView(TemplateView):
    
    def get(self, request):
        # debug というサードのモジュールつかってるけど、もちろん pdbでもいい
        import debug 
       # print(request.META["REMOTE_ADDR"])

これの結果が普段ローカルから接続している 192.168.56.101 ではなく 192.168.56.1 となぜか変わっていた。なので、後者を指定することで対応できた。

結果

CRUD するボタンをおすと HttpResponseRedirect して、そのなかで update/delete/craete とかルーティングして SQL としてはそれぞれ発行してるという挙動がわかりやすかった。

まあ

フルスタックで利用者が多いとこういう手軽なデバッグツールとか作ってくれてる人がいて助かる(あるいはこういうツールがないとどんどんブラックボックスになっていくというのもまああれなんだけど)。あといまは大丈夫だけど、どう MIDDLEWARE とか TEMPLATE_CONTEXT_PROSECCOR を通過しているかとか Django が内部的にどう動いているのかがわかりやすいからなんかあったときにトラブルシューティングに役立つ。テンプレートの継承やそこで発行されているクエリもみれる。