Webアプリ開発における「内部APIモデル」 - Tous Les Jours 攻防記
前回の話は、一回のエントリーでは書ききれない内容でした。。以下もうすこし詳しく書き直してみます。 Webアプリ開発における「内部APIモデル」とは、ネットワーク越しに外部サイトのWebAPIを呼び出すかのごとく、自サイト内のリソースに対して内部専用のWebAPIでアクセスする仕組みを導入し、分散処理を行うモデルのことです。典型的なWebアプリでは、データベースがここでいうリソースに該当するかと思います。 図にすると以下のようなイメージです。 今回、Lang-8で実際に「内部APIモデル」を導入してみたので、気づきの点などをこのエントリーにまとめてみました。 ※導入のいきさつについては、前回のエントリーで触れています。 「内部APIモデル」を採用するメリット Webアプリ開発において「内部APIモデル」を採用するメリットは２つあります。 （１）言語やフレームワークの選択自由度が上がる 現在運
win-django.com - Admin siteでmodelを複数に分割して管理する
Admin siteを便利に使いたい Admin siteでmodelのデータを予めある程度分類できたら便利だと思いませんか。 django.contrib.auth.models.Userを使って試したいと思います。 仕様 Django 1.1以降のバージョンをインストールしてあること。 ユーザ作成 ユーザは以下の設定とします。 test1は is_staff = True, is_superuser = True test2は is_staff = True, is_superuser = False test3は is_staff = False, is_superuser = False admin.py作成 querysetを利用すれば表示するデータを制御できます。 admin.py from django.contrib import admin from django.co
django.db.models.expressions.F - 偏った言語信者の垂れ流し
id:MiCHiLUさんがtrunkにdjango.db.models.Fというのが増えてるとtwitterでつぶやいてたので、さっそく見てみた。 django/expressions.py at master · django/django · GitHub Filters can reference fields on the model フィルタでモデルのフィールドを参照できるとさ。今まではextraのwhereに頼っていたものがfilterでできるようになるので便利。 例えば、 >>> Entry.objects.extra(where=['created_at = updated_at']) が >>> from django.db.models import F >>> Entry.objects.filter(created_at=F('updated_at')) と書ける。
Field/column Queries in Django
One of the neat things making it's way into Django 1.1 is F object queries. The F object is kind of like the Q object as it can be used it queries but it represents a database field on the right hand side of an equality/inequality. For the example I'll use the example models from the "Making Queries" section of the Django Documentation.
モデルフィールドのデフォルト値 - 偏った言語信者の垂れ流し
はまったのでメモ。soundkitchenさんありがとうございます。 モデルでDateTimeFieldなどのフィールドを使用するときに、 mydate = models.DateTimeField(default=datetime.datetime.now()) のようにデフォルト値に"datetime.datetime.now()"を指定することがよくある。 しかし、これだと管理画面で新規作成をした場合には、常に同じ日付が表示されてしまう。 defaultの値を毎回評価するためには、関数を指定する。 つまり、 mydate = models.DateTimeField(default=datetime.datetime.now) のようにする。 Fieldクラスのget_default()で、defaultがcallableかどうか判定してから評価されるので、これでいいみたいです。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。
機能拡張に伴いmodels.pyをcgi経由で変更・反映 - tino_9000の日記
out.jsonに出力しておいたデータを最投入する。 manage.py dumpdataで出力したデータは投入順序を考慮していないので適せん修正する。 cgiに以下の記載。 #!/usr/local/bin/python import cgi import cgitb; cgitb.enable() import os os.environ['DJANGO_SETTINGS_MODULE'] = 'mydiary.settings' print "Content-type: text/html; charset=Shift_JIS\n\n" print "" os.system('python mydiary/manage.py reset diary --noinput') print "reset\n" os.system('python mydiary/manage.py sync
DjangoのORMのすごいところ - 偏った言語信者の垂れ流し
私がDjangoのORMを気に入っているのは、Pythonコードでスマートにクエリセットを作れるからです。 例を書いてみる。 blog/models.py from django.db import models import datetime class Entry(models.Model): title = models.CharField(max_length=100) content = models.TextField() create_date = models.DateTimeField(default=datetime.datetime.now) def __unicode__(self): return self.title こんなモデルを作った。 Qオブジェクトを使ってクエリセットを作ってみる In [1]: from blog.models import Entry
Managerの条件指定 - 初学者の箸置
filter()とかのモデル検索メソッドの条件指定に使えるキーワード引数。 {model}__{fieldname}__{lookuptype}の引数に=で値を与える。例えば1000円未満のレシートならReciept.objects.filter(price__lt=1000)とか。ちょっとだけ変なんだけど、確かに文字列で渡すのではなくて文法要素なのはGOODなのかな（内部ではどうせ文字列操作してるだろう訳でちょっと微妙だけども、文法チェックが入るのは良いのだろう）。動的言語ってのは本当に柔軟だなあ、と改めて思う。 とゆーわけで条件指定に使えるlookuptypeまとめ. gt 大きいもの gte 以上 lt 小さい lte 以下 exact 厳密にマッチ iexact Case Insensitive でマッチ contains 含む icontains Case Insensitive
モデルのsaveが変わったよ。 - Humming Via Kitchen
Django の trunk に queryset-refactor がマージされたタイミングで、 モデルの save メソッドにも改良が加えられてたのでメモメモ。 マージ前(r7476) は save メソッド自体に実際の処理が書かれてた。 # django/db/models/base.py@213行目あたり def save(self, raw=False): dispatcher.send(signal=signals.pre_save, sender=self.__class__, instance=self, raw=raw) # 中略... dispatcher.send(signal=signals.post_save, sender=self.__class__, instance=self, created=(not record_exists), raw=raw) の
django.contrib.auth.models.User 拡張 - Solitaire
プログラミング・ゲーム・Web関係の話がメインかも。 Cell/B.E, Pythonネタ多いかもしれず。 Django は元々認証用のコントリビュートを持っているんだけれど、それだけじゃ自分が扱いたい情報には物足りない。という場合が多いと思う。自分もその口だ。 まず自分が考えたのは、継承してみようか。って事だ。でもこれだと、結構面倒な事が判明。つまりは、他の Django の subframework などが動かなくなる。ということだ。継承後のクラスをどこに作るかにも寄るが、ただデータ増やすだけのためにかなりの変更が必要なので非現実的ということで。 次に考えたのが、普通に外部キーで繋げてしまえばいいんじゃないか？ということだ。 しかし、いまいちどうやればいいのかイメージが沸かなかった。 なので、ちょっとぐぐってみたら日本語でもいくつか情報があったので、紹介。 http://blog.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Netflix FlacorでJSONデータを取得する
Charming Python: Functional programming in Python, Part 3
kndb.jp
http://marinho.webdoisonline.com/blog/p/153/
転送中
http://endlessx.homelinux.com/blog/detail/78/
Djangoでmodels.pyを変更したときにDBに反映させる - YAMAGUCHI::weblog
http://piro-suke.hatenablog.com/entry/20080224/1203813421
http://www.freakydog.de/vorschaubilder-djangos-administration.html