この記事で書いていること ORMを使っていると、知らぬ間に大量のSQLが発行されてる恐れがある クエリ数を発行しないための工夫がいくつかあるので、それを紹介する 新しい使えるテクニックを見つけたら、随時加筆予定 ORMでは知らぬうちに大量のクエリが発行されているかもしれない 私が触ったことのあるフレームワークはRails、Djangoだけなので、ORマッパーがあるのが当たり前という環境で育ってきました。 そのため、DBにアクセスするためにSQLが発行されていることをあまり意識してきませんでした。（お恥ずかしい限りですが） これから職業プログラマーとして成長していくためにはそんなんじゃあかんという訳で、絶賛試行錯誤中です。 今回は私が調べたり、先輩から教えてもらったクエリ数を抑える工夫やテクニックを紹介していこうと思います。 クエリ数を観測するには、「django-debug-toolbar

目的 Djangoでデータベースとやり取りする際に、ORMを使うことが多いかと思います。 ORMは非常に強力ですが、場合によってはレスポンスタイムの悪化を引き起こすことがあります。 今回はその原因となる「N+1」問題についてと、その解決方法を示します。 N+1問題とは データベース上のデータを取得する際に発生する性能の問題です。 一般的に、1つの主データに対して、それに紐づく複数のデータを取得する場合、1回のクエリで主データと全ての紐づくデータを取得することが望ましいとされます。 しかし、ORMを使用した際に、1つの主データに対して、それに紐づく複数のデータを取得する際、1つの主データに対して1回のクエリを発行し、その紐づくデータを1つずつ取得することがあります。 結果 「主データ(1) + 紐づくデータ数(N)」 の数だけクエリが発行され、性能劣化を引き起こします。 N+1問題とは 主デ

Djangoのprefetch_relatedについて prefetch_relatedはDjangoのN+1問題を回避するための機能です。 select_relatedと並び重要なメソッドですが、理解が曖昧な部分があったので整理したいと思います。 DjangoのSQLが実行されるタイミングについて DjangoがDBを叩きにいくタイミングについて確認しておきます。 1.メソッドが呼ばれたタイミング いくつかのメソッドはクエリセットは返さずに、呼び出されたタイミングでDBを叩きに行きます。 代表的なものをあげておきます。 メソッド名 機能

はじめに こんにちは。T.H.です。 久しぶりのブログ記載になります。今回はdjangoのお話になります。 結論 djangoのORマッパーは使いやすくて良いですね。 djangoでの多対多表現 djangoにおけるmodelのrelationをあらわすものにManyToManyというものがあります。 これは、多対多の関係性を設定するためのものです。 (ここでは多対多そのものの説明は省きます。) 多対多の関係性はモデル図に書き起こす場合は特に問題ないのですが、 MySQLなどのリレーショナルDBではテーブル間で多対多を直接表現する手段を持たないため、ユーザー側で実現可能なようにテーブルを設計する必要があります。 ところがdjangoのORマッパーはその関係性を直接書き起こすことが出来ます。 これが非常に便利でして、覚えておくとよい、といいますか、使用しないとmodelの記述が大変です。 ま

継承① MultipleObjectTemplateResponseMixin このMixinはTemplateResponseMixinを継承し、テンプレートの指定やHTTPレスポンスの生成を行います。 継承② BaseListView MultipleObjectMixinとViewを継承しており、ここでリストの取得やページネーション、コンテキストデータの生成が行われます。 Viewクラスのas_view()メソッドにより、適切なHTTPメソッドへのマッピングが行われます。 MultipleObjectMixinクラス このクラスでは、リストの取得やページネーション、コンテキストデータの生成などが行われます。 class MultipleObjectMixin(ContextMixin): allow_empty = True queryset = None model = None

Djangoで多対多の関係を作りたいときはManyToManyフィールドを使いますが、その引数としてthroughを使うことができます。 throughを使えば独自の中間テーブルを使うことができます。その使い方についてです。 ManyToManyFieldを使った時の参照や逆参照の仕方は、こちらの記事で書いています。 ManyToManyフィールドを使うと、中間テーブルは自動生成される まずは、throughオプションを使わない単純なManyToManyFieldの例からです。 ManyToManyFieldを使うと、Djangoは自動で中間テーブルを作成してくれます。（中間テーブルのテーブル名は、モデル名とフィールド名から自動で命名されます。db_tableオプションを使えば、自分で命名することもできます。） models.py from django.db import models

そして、これをマイグレーションする時、警告が出る。null禁止であるcategoryにはフィールドオプションのdefaultがない。この矛盾の対策は3通りある。 【対策1】categoryフィールドにnull=Trueとblank=Trueのフィールドオプションを指定、未分類を許可する 【対策2】migrationsディレクトリとdb.sqlite3を削除し、一からマイグレーションファイルを作り直し 【対策3】migrationsディレクトリとdb.sqlite3を削除できない場合、1度限りのデフォルト値を入れる 参照元:DjangoでYou are Trying to add a non-nullable fieldと表示されたときの対策【makemigrations】 【対策1】categoryフィールドにnull=Trueとblank=Trueのフィールドオプションを指定、未分類を許

Djangoで実行されたSQLクエリのRAWデータを確認する方法について解説。Djangoの実行処理を高速化するためにはまずSQLクエリの確認から始めるのがコツ。 Python Django プログラミング学習この記事は約 分で読めます。（文字） 多量のデータなどを処理すると途端にDjangoアプリケーションの実行速度が落ちてきます。大半の原因は無駄なSQLクエリの発行。 そこで今回は、まずどのようなSQLクエリが発行されているのかを実際に実行された生のSQLクエリを見て確認する方法について解説していきます。 connection.queriesで生のSQLクエリを確認Djangoで生のSQLクエリ実行も確認するために利用するのはconnection.queries。 connection.queriesconnection.queriesを利用すると実際に発行されたSQL文とその実行にか

Serializer 何をするもの？ データに対してシリアライズとデシリアライズを行うところ。 デシリアライズとは？ 入力データを元になんらかのオブジェクトを作成すること。 まずは基本の基本からやるとして、こういうモデルがあるとする。 class Book(object): def __init__(self, title, author, price, created=None): self.title = title self.author = author self.price = price self.created = created or datetime.now() class BookSerializer(serializers.Serializer): title = serializers.CharField(max_length=255) author = seria

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?