هیچی دیگه همچی داشت یادم میرفت گفتم اینجا بزارم قبل هر مصاحبه بخونم :)

سوال جنگویی:
اگه یک مدل داشته باشیم به شکل زیر:

from django.db import models


class Fruit(models.Model):
    name = models.CharField(max_length=100, primary_key=True)

بعد بیاییم این کد رو اجرا کنیم:

>>> fruit = Fruit.objects.create(name="Apple")
>>> fruit.name = "Pear"
>>> fruit.save()

اومدیم یک آبجکت ساختیم و ذخیره اش کردیم. بعد فیلم name که پرایمری‌کی بود رو آپدیت کردیم و ذخیرش کردیم.

حالا سوال اینه، در این لحظه چه اتفاقی میوفته؟ آیا ارور میخوریم یا ابجکت آپدیت میشه یا اتفاق دیگه ای میوفته؟

@TorhamDevCH

اتفاقی که میوفته اینه که از اونجایی که فیلد name پرایمری‌کی و پرایمری‌کی ها Read-Only هستن شما نمیتونی آپدیتش کنی و اگه تلاش برای آپدیت کردنش کنی، جنگو میاد یک آبجکت جدید میسازه دقیقا با همون اطلاعات قبلی ولی فقط پرایمری‌کی رو تغییر میده. در نهایت شما دوتا آبجکت Fruit خواهید داشت.
@TorhamDevCH

داخل جنگو ۳ نوع Model inheritance داریم. یعنی مدل‌های دیتابیس میتونن به سه شکل از هم دیگه ارث بری کنند.
۱. Abstract base classes
۲. Multi-table inheritance
۳. Proxy models
که فعلا با دوتا اول کار ندارم و احتمالا بدونید چی هستند. ولی سومی همیشه برای من گنگ بود که چی هست و چیکار میکنه. ولی داشتم داکیومنت جنگو میخوندم که رسیدم به توضیح پروکسی‌مدل و تمام، بهترین توضیحی بود که خوندم و تا آخر یادم خواهد ماند :)
if you only want to modify the Python-level behavior of a model, without changing the models fields in any way, you can use Proxy models.
اگر فقط و فقط میخوایید تو لول فانکشنالیتی مدل تغییر ایجاد کنید. مثلا فانکش foobar میخایید یک تغییر بدید برای نسخه جدید ولی میخوایید نسخه قدیمی باقی بمونه میایید از پروکسی استفاده میکنید.
حالا شما یک مدل دارید دقیقا با همون مشخصات ولی فانکشنالیتی فانکشن foobar فرق میکنه.
تو مثال خود داکیومنت یک فانکشنالیتی اضافه کرده:

from django.db import models


class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)


class MyPerson(Person):
    class Meta:
        proxy = True

    def do_something(self):
        # ...
        pass

@TorhamDevCH

یک نکته رو باید در نظر داشته باشید که ساخت یک مدل پروکسی یک تیبل جدید داخل دیتابیس نمیسازه و از همون مدل قبلی استفاده خواهد کرد. تو این مثال مدل MyPerson دقیقا روی همون تیبل دیتابیسی که مدل Person کار میکنه کار خواهد کرد، پس اگه یک چیزی رو اپدیت کنید و بسازید و ... روی همون تیبل دیتابیسی انجام میدید که اگر با Person انجام میدادید.
@TorhamDevCH

شاید برای شما هم سوال بود که چطور SQL کوئری‌هایی که با ORM جنگو میزنیم رو ببینیم؟

https://b0uh.github.io/django-show-me-the-sql.html

@TorhamDevCH

یک نکته درباره primary key داخل #جنگو اینه که شما میتونید برای هر app به شکل خاص primary key خاص خودش رو داشته باشید. مثلا برای یک app از big integer استفاده کنید و برای یکی از UUID این رفتار رو برای هر اپ میتونید به مشخص کردن AppConfig.default_auto_field مشخص کنید. حالا #django این قابلیت رو هم بهتون میده که جدا از انتخاب دونه دونه برای هر اپ یک حالت گلوبال در نظر بگیرید که اگر مخصوص اپ ست نکرده باشید از اون استفاده میکنه که پیش‌فرض خود جنگو BigIntegerField در نظر میگیره و میشه با تغییر دادن DEFAULT_AUTO_FIELD داخل settings.py به شکل گلوبال تغییرش داد

@TorhamDevCH

این توانایی که خود #جنگو بهتون میده ولی از trick دیگه هم میتونید استفاده کنید و اون هم ساختن یک مدل ابسترکت و بقیه مدل‌ها ازش ارث ببرن.
مثال:

from django.db import models 
from uuid import uuid4
  
  
class Base(models.Model): 
    id = models.UUIDField(default=uuid.uuid4, primary_key=True)
  
    class Meta: 
        abstract = True

از اونجایی که اگه داخل مدل #django فیلدی داشته باشید که داخلش primary_key مقدار True داشته باشه جنگو دیگه از اون مقدار دیفالتی که مشخص کردید (هردو حالت دو پیام بالا) استفاده نمیکنه و میاد از این فیلد استفاده میکنه. حالا شما میتونید بقیه مدل‌هاتون رو از این مدل ارث بری کنید و دیگه نگران مقدار id نباشید.

@TorhamDevCH

کوئری‌های #جنگو lazy هستند

اما این یعنی چی؟ کلا برای فهمیدن موضوع lazy فکر کنم این ویدیو شهریار شریعتی (Laziness in Python تنبلی در پایتون ) خوب باشه و بتونید بفهمیدش، یا اینکه نسخه انگلیسی از Computerphile.

به این مثال توجه کنید:

>>> q = Entry.objects.filter(headline__startswith="What")
>>> q = q.filter(pub_date__lte=datetime.date.today())
>>> q = q.exclude(body_text__icontains="food")
>>> print(q)

این مثال خود داکیومنت جنگوعه. اینجا با ۳ تا کوئری زدیم و یکچیزی از دیتابیس درخواست کردیم، حالت عادی با خودتون میگید خب الان ۳ بار دیتابیس hit شده (درخواست رفته براش) اما در حقیقت فقط یک بار دیتابیس هیت شده و اون هم تو خط آخر جایی که کوئری رو پرینت کردیم. جنگو تنها و تنها زمانی دیتابیس رو با کوئری که شما زدید hit میکنه که دیتا رو درخواست کرده باشید. حالا چه پرینت باشه چه حلقه بزنید روش و ... و این نتیجه لیزی بودن کوئری هاست. تو کد بالا در حقیقت خط اول یک کوئری ساختیم، خط دوم یک فیلتر به همون کوئری اضافه کردیم و در نتیجه یک کوئری جدید ساخته شده و خط سوم هم همینطور و در نهااااااااااایت در خط چهارم یک کوئری به دیتابیس زدیم که داخش گفته هدلاین با what شروع شده باشه تاریخ پابلیش کوچیکتر از امروز باشه اونایی رو میخام که داخل بدنه شو کلمه food وجود داره.

@TorhamDevCH

خب من یک چیز خیلی جالب و در این حال گیج‌کننده درباره ORM #جنگو فهمیدم.

تو پیام قبلی گفتم که کوئری‌های #django دقیقا چه زمانی واقعا اجرا میشن. اما اینجا یک نکته دیگه‌ای هم هست، جنگو نتیجه کوئری‌هارو کش میکنه.

و این خیلیییییییییییی مهمه، یعنی بعضی از جاها که فکر میکنید جنگو قرار دیتابیس هیت کنه هیت نمیکنه و از کش استفاده میکنه و بعضی جاها که فکر میکنید قرار کش استفاده کنه واقعا هیت میکنه. دونستن و فهمیدن این که چه زمانی کش استفاده میکنه چه زمانی نه حدود ۲ ساعت از من زمان گرفت :) ولی تو این پست توضیح میدم چیزی که فهمیدم رو.

اول این قانون تو ذهنتون داشته باشید: هر چیزی که باعث ایجاد یک QuerySet جدید بشه، باعث هیت به دیتابیس خواهد شد اگر اون کوئری اجرا بشه.

به مثال زیر دقت کنید:

users = User.objects.all()
print(users)

if users:
    for u in users:
         print(u)

خب تو این مثال فکر میکنید چندبار دیتابیس توسط جنگو هیت میشه؟ اگه ماجرا کش کردن ندونید ولی ماجرا اینکه چه زمانی واقعا اجرا میشه رو بدونید احتمالا با خودتون میگید ۳ بار داخل این کد جنگو دیتابیس رو هیت میکنه.

اما اگر من بگم فقط دو بار دیتابیس هیت میکنه چی؟

بزارید توضیح بدم. تو خط اول ما صرفا کوئری رو ساختیم و هیچ هیتی به دیتابیس نزدیم. تو خط دوم ما کوئری پرینت کردیم و اینجا اولین هیت به دیتابیس خورده میشه، ولی یک نکته اینجاست وقتی شما یک کوئری رو پرینت میکنید جنگو نمیاد کل کوئری رو اجرا کنه چون منطقی نیست!، مثلا اگر کوئری شما هزارتا خروجی داشته باشه شما اون هزارتا رو که داخل پرینت نمیخایید، در نتیجه جنگو فقط یک بخش از کوئری رو ران میکنه یا به عبارت دیگه از LIMIT استفاده میکنه!. تو این خط هیچ کش کردنی اتفاق نمیوفته(جلوتر میگم چرا)

خط بعدی ما از if استفاده کردیم و اینجا یک هیت دیگه به دیتابیس میخوره اما این‌بار کل کوئری اجرا میشه و اینجاست که جنگو ریزالت کوئری میگیره و داخل کش ذخیره میکنه. تو خط بعدی که اومدیم حلقه زدیم روی کوئری جنگو دیگه نمیاد به دیتابیس درخواست بزنه و از کش استفاده میکنه!

در نتیجه اینجا فقط ۲ بار دیتابیس هیت میخوره.

ادامه داخل پیام بعد...

@TorhamDevCH