یک مبحثی که خیلی وقت‌ها آدم‌های رو داخل #جنگو گیج میکنه موضوع Aggregation هستش. برای مثال کوئری پایین:

>>> from django.db.models import Avg, Max, Min
>>> Book.objects.aggregate(Avg("price"), Max("price"), Min("price"))
# {'price__avg': 34.35, 'price__max': Decimal('81.20'), 'price__min': Decimal('12.99')}

خب این کوئری مشخصه چه کاری داره انجام میده، همه میتونن بفهمنش مخصوصا وقتی خروجی کوئری رو میبینن، اما اگر ازشون بپرسید خب Aggregation چی هستش هیچ ایده ای ندارن! و این ماجرا از ضعف در دانش SQL سر چشمه میگیره. چون خیلی از آدم‌هایی که دارن #django کار میکنن مستقیم سراغ جنگو اومدن و نرفتن چیزهای دیگه رو مطالعه کنن و یاد بگیرن.

اسم Aggregation داخل ORM جنگو مستقیما از SQL میاد. در SQL یک سری فانکشن وجود داره که بهشون Aggregation functions میگن و کارشون خلاصه سازی اطلاعات:
MIN() - returns the smallest value within the selected column
MAX() - returns the largest value within the selected column
COUNT() - returns the number of rows in a set
SUM() - returns the total sum of a numerical column
AVG() - returns the average value of a numerical column

و خب شما میتونید داخل کوئری‌های SQL ازشون استفاده کنید و دیتا خروجی رو خلاصه سازی کنید و یا یک آمار ازش دربیارید. مثلا میانگین قیمت کتاب‌های تو سال اخیر و ...
یک کوئری مثال برای Aggregation میتونه این باشه:

SELECT AVG(Price) as price_avg FROM Books WHERE puddate='2023-01-01';

خب از اونجایی که ORM جنگو در نهایت قرار کار همین SQL نوشتن برای شما انجام بده و کوئری‌ شمارو به SQL تبدیل کنه شما دقیقا همین کوئری میتونید داخل جنگو به این صورت بنویسید:

>>> from django.db.models import Avg
>>> from datetime import datetime
>>> Books.objects.filter(pubdate=datetime(2023, 1, 1)).aggregate(price_avg=Avg("price"))

میتونید لیست فانکشن‌های Aggregation خود SQL داخل این لینک ببینید و ساپورت جنگو هم میتونید داخل این لینک ببینید.

در نهایت از دانش SQL غافل نباشید و حتما یادش بیگیرید. هرچی بیشتر SQL بدونید زندگی راحت‌تری خواهید داشت.

@TorhamDevCH

کوئری raw زدن در #جنگو

درسته #django یک ORM خوب داره و تقریبا تمام چیزهایی که لازم دارید رو ساپورت میکنه اما شما میتونید داخل جنگو مستقیم کوئری SQL ران کنید!

ران کردن این کوئری‌ها به صورت raw میتونه تو دو لایه در جنگو انجام بشه. یک در لایه مدل خودتون و دومی تو لایه پایین تر مستقیم با کانکشن دیتابیس.

تو حال اول جنگو سعی میکنه که خروجی SQL را براتون Map کنه و خروجی دوباره مدل براتون برگردونه حتی وقتی دارید raw میزنید مثال:

مدل فرضی:

class Person(models.Model):
    first_name = models.CharField(...)
    last_name = models.CharField(...)
    birth_date = models.DateField(...)

کوئری مثال:

Person.objects.raw("SELECT * FROM myapp_person")

این کوئری دقیقا معادل objects.all() و جنگو خروجی رو بر اساس اسم فیلدها مپ میکنه به مدل. این مهمه ها! بر اساس اسم فیلد‍! یعنی شما میتونید کوئری رو حتی رو یک تیبل دیگه بزنید و تا زمانی که اسم فیلدا خروجیتون با مدل یکی باشه جنگو اون‌هارو مپ میکنه. مثال:

>>> Person.objects.raw(
...     """
...     SELECT first AS first_name,
...            last AS last_name,
...            bd AS birth_date,
...            pk AS id,
...     FROM some_other_table
...     """
... )

بله میتونیم از AS استفاده کنیم و اسم فیلدا مشابه مدلمون بزاریم. خود جنگو هم یک فیچر داره که براتون همین AS رو میزنه!

>>> name_map = {"first": "first_name", "last": "last_name", "bd": "birth_date", "pk": "id"}
>>> Person.objects.raw("SELECT * FROM some_other_table", translations=name_map)

میتونید از پارامتر translations استفاده کنید برای اینکار.

میتونید برخی از فیلدها رو انتخاب نکنید!

برای مثال:

>>> for p in Person.objects.raw("SELECT id, first_name FROM myapp_person"):
...     print(
...         p.first_name,  # This will be retrieved by the original query
...         p.last_name,  # This will be retrieved on demand
...     )
...

برای مثال داخل این raw کوئری ما فیلد last_name رو انتخاب نکردیم. حالا چه اتفاقی افتاده؟ همچنان اگه شما فیلد last_name صدا بزنید مشکلی پیش نمیاد و دریافتش میکنید ولیییییی جنگو از اونجایی که اون فیلد داخل کوئری وارد نکرده بودید و خروجیش رو نداشته خودش میاد همون لحضه دوباره یک درخواست به دیتابیس میزنه و اون دریافت میکنه!


لایه خود کانکشن

اگه این مپینگ رو نمیخایید و کلا میخوایید یک کوئری مستقیم بزنید مثل زمانی که از یک کتابخونه معمولی تو پایتون برای دیتابیس استفاده میکنید میتونید از connection در جنگو استفاده کنید! مثال:

from django.db import connection


def my_custom_sql(self):
    with connection.cursor() as cursor:
        cursor.execute("UPDATE bar SET foo = 1 WHERE baz = %s", [self.baz])
        cursor.execute("SELECT foo FROM bar WHERE baz = %s", [self.baz])
        row = cursor.fetchone()

    return row

خروجی یک لیست از نتایج خواهد بود. البته میتونید با یک حرکت ساده این لیست مپ کنید خودتون و در نهایت یک دیکشنری داشته باشید.

def dictfetchall(cursor):
    """
    Return all rows from a cursor as a dict.
    Assume the column names are unique.
    """
    columns = [col[0] for col in cursor.description]
    return [dict(zip(columns, row)) for row in cursor.fetchall()]

و‌ آخرین نکته اینکه وقتی دارید از raw استفاده میکنید دیگه اسلایس کردن رو لول کوئری لیمیت نمیزاره و بهتره از LIMIT استفاده کنید داخل خود کوئری SQL

@TorhamDevCH

Transaction per-request in #django


#جنگو قابلیت انجام ترنزکشن با دیتابیس به شما میده در چندید حالت مختلف یکی از حالت‌ها ترنزاکشن بر هر ریکوئستِ، یعنی چی؟ یعنی جنگو برای هر ریکوئستی که شما میگیرید یک ترنزاکشن باز میکنه یا به عباری برای هر ویو فانکشن شما یک atomic() ران میکنه! این قابلیت به شکل پیشفرض غیر فعاله ولی میتونید با اضافه ATOMIC_REQUESTS داخل کانفیگ دیتابیسی که میخوایید این حرکت باهاش بزنید این قابلیت فعال کنید.
این کار هر ریکوئست شمارو داخل یک ترنزاکشن warp میکنه و اگر ویو شما هر اروری بده ( ارور raise کنه ) ترنزاکشن rollback میخوره و تغییرات اعمال نمیشه.

@TorhamDevCH

Transaction in #django

اگه نمیدونید به طور کلی ترنزاکشن چیه میتونید به این لینک سر بزنید. ولی خیلی خلاصه بخوام بگم به انجام چندتا کوئری مختلف ولی در یک unit ترنزاکشن میگن، یعنی شما ۳ تا کوئری انجام میدی، اگه حتی یکدونه از اون ۳ تا ارور بخوره بقیه ۲ تا هم هر تغییری داده باشن اون برمیگردونن یا به اصطلاح Rollback میکنه.

حالا #جنگو این قابلیت به شما میده که از این فیچر دیتابیس‌ها داخل کدتون استفاده کنید برای این کار میتونید از transaction.atomic استفاده کنید، این فانکشن هم قابلیت استفاده به عنوان دکوریتور رو داره هم کانتکس منیجر


به عنوان دکوریتور:

@transaction.atomic()
def something():
     do_database_update()
     do_database_delete()

یا به عنوان کانتکس منیجر:

def something():
     with transaction.atomic():
            do_database_update()
            do_database_delete()

تو هر دو کد اگر اتفاقی داخل یکی از فانکشن ها بیوفته یعنی اگر ارور raise بشه کوئری‌ها و تغییراتی که رو دیتابیس اعمال شده همه rollback میشه و برمیگرده، شما میتونید چندتا ترنزاکشن به صورت nested هم انجام بدید برای مثال:

with transaction.atomic():
       do_update():
       with transaction.atomic():
               do_delete()

تو اینجا باید یک نکته رو در نظر داشته باشید که جنگو هربار که یک nested میزنید از بیرون به داخل میره و هربار که وارد یک مرحله عمیق تر میشه یک savepoint میسازه از نستد بالایی یعنی اول ترنزاکشن آپدیت انجام میده بعد savepoint میسازه که بفهمه چیکار کرده بعد میره دومی، میتونید ساخت savepoint رو غیر فعال کنید با پاس دادن savepoint=false به فانکشن اتومیک که توصیه جنگو اینه که اینکار نکنید مگر اینکه واقعا مشکل پرفورمنس بخورید.

در پست بعدی درباره Transaction.on_commit صحبت میکنم :)

@TorhamDevCH

مشکل concurrency چیه و چطوری میتونیم داخل #جنگو حلش کنیم؟

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

فرض کنید شما یک سیستم بانکی دارید و داخل این بانک یک حساب مشترک دارید بین user1 و user2. هردو این یوزرها به این حساب دسترسی دارن یوزر اول پرداخت کننده است و یوزر دوم برداشت کننده حالا فکر کنید بالانس(موجودی) حساب ۱۰۰۰ دلاره.

در همین لحظه که ما هستیم user1 میخواد ۱۰۰ دلار به حساب واریز کنه و دقیقا همزمان باهاش user2 میخواد ۱۰۰ دلار برداشت کنه. سوال اینه که در آخر این برداشت و واریز موجود یا همون بالانس حساب چقدر خواهد بود؟ جواب منطقی ما اینه که بالانس همون هزار دلار خواهد بود چون ۱۰۰ دلار اومد و ۱۰۰ دلار هم رفت و آره! اگه برنامه ما فقط و فقط یک پروسس باشه این ۲ درخواست به ترتیب اجرا خواهد شد و بالانس همون هزار دلار میشه اما اگه برنامه بیشتر از یک پروسس باشه چه اتفاقی میوفته؟

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

۱. یوزر اول درخواست میزنه و موجودی ۱۰۰۰ دلار رو دریافت میکنه
۲. یورر اول موجودی آپدیت میکنه به ۱۱۰۰ دلار .

۳. یوزر دوم دقیقا تو همون لحظه درخواست میزنه و قبل اپدیت شدن موجودی اون میگیره و نتیجه موجودی برای ۱۰۰۰ دلاره
۴. ازش ۱۰۰ تا کم میکنه و ۹۰۰ رو به عنوان بالانس ذخیره میکنه.


و درنهایت موجودی شد ۹۰۰ دلار! این ماجرا میتونست برعکس هم اتفاق بیوفته و موجودی بشه ۱۱۰۰ دلار که همش نتیجه یک چند صدم ثانیه اختلاف بین ریکوئست یک و دو بود. نکته اصلی این بود که اینا قبل اینکه اون یکی موجودی آپدیت موجودی رو میخوندن و داخل مموری ذخیره میکردند در نتیجه تو اپدیت هم اشتباه اپدیت میکردند.


حالا که فهمیدید ماجرا از چه قرار شما میتونید داخل #django با استفاده از select_for_update و ترنزاکشن که پست‌ها قبل توضیح دادم این ماجرا حل کنید. ( در حقیقت جنگو ماجرا رو حل نمیکنه بلکه با استفاده از متدها شما به جنگو میگید کوئری بسازه که نتیجه اش این بشه که دیتابیس براتون یک لاک رو row که میخوایید آپدیت کنید بگیره)


حالا روش استفاده و توضیحات بیشتر میتونید تو مقاله پایین بخونید. این پست خلاصه‌ای کوتاه از مقاله زیر بود ( خود مقاله هم کوتاه)

https://www.sankalpjonna.com/learn-django/managing-concurrency-in-django-using-select-for-update

@TorhamDevCH

آپدیت کردن چند آبجکت به صورت همزمان در #جنگو

فریم‌ورک #django قابلیت آپدیت کردن دیتاها رو به روش ها مختلف داره که خیلی ها یا ازش بی خبر ان یا استفاده نمیکنن. بیایید ببینیم هر کدوم رو کجا استفاده کنی بهتره :)

مدل فرضی:

class Records(models.Model):
    name = models.Charfield()
    balance = models.InetegerField()
    country =models.CharField()

خب فرض کنید ما یک هدیه به مناسب عید نو روز میخواییم به کاربرا بدیم، مثلا میخاییم نفری ۲ هزار تومن هدیه بدیم D:

حالا چند روش وجود داره.

روش اول ( نوب):

users = Records.objects.all()

for user in users:
    user.balanc = user.balance + 2
    user.save()

خیلی ساده و البته درب و داغون در خیلی جهات. مشکل اول اینه که ما رو همه کاربرا حلقه میزنیم و هر بار آپدیت رو روی کاربرا صدا میزنیم یعنی برای هر یوزر یک درخواست اپدیت به دیتابیس میره که اگه ۱ میلیون یوزر داشته باشیم ۱ میلیون درخواست میره :).

( تو اینه پست به اینکه باید از F استفاده کنید یا کانکارنسی و اینا هندل کنید اشاره نمیکنم، پست‌ها قبلی بخونید)

حالا روش بهتر چیه؟

روش بهتر:

user = Records.objects.update(balance=F("balance") + 2 )

همینقدر ساده :)


سناریو دوم: با بک‌اند یک بازی خفن رو داریم توسعه میدیم، داخل این بازی هر هفته یک ایونت اتفاق میوفته که افرادی که اون رو تموم کنن در آخر هفته یک تایتل به کنار اسمشون اضافه میشه و همچنین اگه امتیاز بالاتر از ۱۰ کسب کرده باشن به بالانس پول داخل گیم‌شون هم ۱۰۰ تا گلد اضافه میشه.


حالا بیایید فقط کوئری آپدیت این بهش ببینیم، فرض کنید این کوئری آخر هفته اجرا میشه. ( این فیلدا تو مدل فرض نداریم دیگه خودتون فرض کنید هست 😂❤️)

users = Records objects.fileter(done_weekly=True)

for user in users:
    user.name = "Grunt " + user.name
    if user.weekly_score >= 10:
         user.balance = user.balance + 100

    user.save()

خب همینطور که خیلی معلومه مشکلات فراوان داخلش هست. بزرگ‌ترین مشکلش اینه که هر بار برای هر کاربر یک درخواست آپدیت میدیم که میشهه همون مشکل بالا، آما آیا این بار میشه از روش بالا استفاده کرد و اینو فیکسش کرد؟ نه
روش بالا زمانی کاربرد داره که فیلدها قراره یک مقداری ثابتی به همشون داده بشه، اینجا بعضی ها ۱۰۰ تا گلد میگیرن بعضی ها نه پس کار نمیکنه، اینجا ما میتونیم از فانکشن bulk_update جنگو استفاده کنیم.

همون حلقه بالا رو میزنید با این تفاوت که داخلش .save رو صدا نمیزنید و تمام آبجکت‌ها رو داخل مموری آپدیت میکنید و بعد همچین حرکتی میزنید:

Records.objects.bulk_update(updated_users_list)

و تموم همرو با هم آپدیت میکنید با یک درخواست اینجا حتی میتونید یک قدم جلوتر برید و با اضافه کردن updated_fields به ورودی فانشکن و مشخص کردن اینکه دقیقا دوتا فیلد بالانس و نام فقط قرار آپدیت بشه بهترش کنید!

از این به بعد بهتر آپدیت کنید :)

@TorhamDevCH

💎 سایت مپ (sitemaps) درجنگو 💎

امروز میخوایم با همدیگه یکی از ابزارهای خیلی کاربردی در دنیای Django رو بشناسیم. چیزی که بهمون کمک میکنه تا سایت‌مون رو بهتر و سریع‌تر برای موتورهای جستجو بهینه کنیم.

❓ حالا Django sitemaps چیه؟
خب، فرض کنین سایتتون یه باغچه بزرگه. هر صفحه سایتتون هم یه گل قشنگ تو این باغچه. حالا Django sitemaps مثل یه نقشه کامل از این باغچه‌ست که به موتورهای جستجو میگه هر گل کجا قرار داره و چه ویژگی‌هایی داره. ️
این نقشه به موتورهای جستجو کمک میکنه تا راحت‌تر توی سایت شما گشت بزنن و صفحات مهم رو سریع‌تر پیدا کنن. اینجوری هم کاربران زودتر به اطلاعات دلخواهشون میرسن و هم سایتتون رتبه بهتری تو نتایج جستجو میگیره. ✅

❓ چرا از Django sitemaps استفاده کنیم؟

1⃣ بهبود سئو: با ایجاد یک sitemap کامل، موتورهای جستجو راحت‌تر صفحات سایتتون رو ایندکس میکنن و در نتیجه سایتتون توی نتایج جستجو بالاتر میاد.

2⃣ افزایش سرعت لود: sitemap به موتورهای جستجو میگه کدوم صفحات مهم‌ترن و باید زودتر بررسی بشن. اینجوری موتورهای جستجو وقت کمتری رو برای پیدا کردن صفحات مهم تلف میکنن.

3⃣ مدیریت بهتر صفحات: با استفاده از sitemaps میشه به راحتی صفحات سایت رو مدیریت کرد و صفحات اضافی یا قدیمی رو حذف کرد.

❓چطور Django sitemaps رو پیاده‌سازی کنیم؟ ️

1⃣ نصب پکیج: اول از همه باید پکیج django-sitemaps رو نصب کنیم. برای این کار کافیه تو ترمینال پروژهتون این دستور رو

بزنید:

pip install django-sitemaps 

2⃣ اضافه کردن به INSTALLED_APPS: بعد از نصب پکیج، باید اون رو به لیست اپلیکیشن‌های پروژه اضافه کنیم. تو فایل settings.py پروژهتون، 'django_sitemaps' رو به لیست INSTALLED_APPS اضافه کنید.

3⃣ ایجاد کلاس Sitemap: حالا باید یه کلاس از کلاس Sitemap که توی پکیج django_sitemaps تعریف شده، ایجاد کنیم. تو این کلاس، مشخص میکنیم کدوم مدل‌ها رو میخوایم توی sitemapمون قرار بدیم و چه فیلدهایی رو برای هر مدل میخوایم ایندکس کنیم.

from django.contrib.sitemaps import Sitemap
from .models import Post

class PostSitemap(Sitemap):

     changefreq = "weekly" 
     priority   = 0.9 

      def items(self): 
           return Post.objects.all()

      def lastmod(self, obj): 
           return obj.publish_date 

      def location(self, item):
           return
reverse('home:post-detail',kwargs={'    slug':item.slug})
    

 
4⃣ ایجاد URL برای Sitemap: در نهایت باید یه URL برای دسترسی به sitemap ایجاد کنیم. این کار رو توی فایل urls.py پروژه انجام میدیم.

from django.contrib.sitemaps.views import sitemap from django.urls import path 
from .sitemaps import PostSitemap

sitemaps = {'posts': PostSitemap}

urlpatterns = [path('sitemap.xml', sitemap, {'sitemaps': sitemaps}, name='django.contrib.sitemaps.views.sitemap')] 

5⃣ ارسال Sitemap به موتورهای جستجو: بعد از ایجاد sitemap، آدرس اون رو به کنسول جستجوی گوگل و سایر موتورهای جستجو ارسال کنید.

⭕️ نکته: برای اینکه موتورهای جستجو به طور خودکار sitemap رو پیدا کنن، بهتره از فایل robots.txt استفاده کنید و آدرس sitemap رو داخل اون قرار بدید.

✅ خلاصه:
خب Django sitemaps یه ابزار قدرتمند برای بهبود سئوی سایت هست. با استفاده از این ابزار، موتورهای جستجو بهتر میتونن محتوای سایتتون رو درک کنن و در نتیجه سایتتون توی نتایج جستجو بالاتر میاد.

امیدوارم این آموزش براتون مفید بوده باشه. اگه سوالی داشتین، حتما بپرسید.

بنظرتون پست بعدی راجب چی باشه؟

#Django #sitemap #seo #python #برنامه_نویسی

💎 شورت کات ها درجنگو 💎
توی این پست میخوام درمورد یکسری شورتکات هایی که کمتر کسی بهشون توجه میکنه رو معرفی کنم

1⃣ render_to_string 🧩
این شورتکات یه پله بالا تر از render هست. اگه می‌خوای تمپلیت رو به یه رشته (string) تبدیل کنی، مثلا برای ارسال ایمیل یا ساختن پیام خاص، render_to_string کارت رو راه میندازه. خیلی شیک و مجلسی می‌تونی تمپلیت رو رندر کنی و به جای HTML کامل، فقط رشته رو داشته باشی:

from django.template.loader import render_to_string

def send_email():
    message = render_to_string('email_template.html', {'key': 'value'})
    # حالا می‌تونی message رو به عنوان متن ایمیل بفرستی

2⃣ resolve_url 🔗
اگه تا حالا از reverse استفاده کردی، این یکی هم خیلی شبیه به اونه ولی یه خورده هوشمندتر. resolve_url می‌تونه هم نام ویو رو به URL تبدیل کنه و هم خودش چک می‌کنه که اگه ورودی URL باشه، مستقیم همون رو برگردونه. پس دیگه نیاز نیست نگران باشی چی بهش می‌دی:

from django.shortcuts import resolve_url

def my_view(request):
    url = resolve_url('some-view-name-or-url')
    # ادامه کارا

3⃣  HttpResponsePermanentRedirect 🚦
شاید با HttpResponseRedirect آشنا باشی، ولی این یکی یه Redirect دائمی (کد 301) برمی‌گردونه. این وقتی خوبه که می‌خوای URL جدید رو دائمی کنی و به موتورهای جستجو بگی که این مسیر دیگه همیشه اینجاست:

from django.http import HttpResponsePermanentRedirect

def my_view(request):
    return HttpResponsePermanentRedirect('/new-url/')

4⃣ Http404 🚫
اگه دوست داری یه ارور 404 رو مستقیم دستی بندازی، Http404 بهترین گزینه‌ست. این طوری می‌تونی خودت خیلی شیک کنترل کنی که کجاها ارور 404 داده بشه:

from django.shortcuts import Http404

def my_view(request):
    if not some_condition:
        raise Http404("این صفحه وجود نداره!")
    # ادامه کارا

5⃣ get_current_site 🌍
اگه تو پروژه‌های پیچیده‌تر می‌خوای بدونی که کاربر الان تو کدوم سایت یا دامنه قرار داره (مثلا تو پروژه‌هایی که از multi-site استفاده می‌کنن)، get_current_site خیلی کاربردیه:

from django.contrib.sites.shortcuts import get_current_site

def my_view(request):
    current_site = get_current_site(request)
    # حالا می‌تونی با current_site هر کاری کنی

این شورتکات‌ها می‌تونن واقعاً تو پروژه‌های پیچیده‌تر جنگویی به کارت بیان و کارت رو راحت تر کنن.

امیدوارم این لیست براتون مفید باشه ✌️

#Django #Python #کدنویسی #شورتکات #توسعه_وب #برنامه_نویسی

@ninja_learn_ir

💎 عملیات‌های IO Bound و CPU Bound در جنگو 💎

امروز می‌خوایم درباره عملیات‌های IO Bound و CPU Bound صحبت کنیم و اینکه این دو نوع عملیات چطور روی عملکرد اپلیکیشن‌های جنگو تاثیر میذاره.

حالا IO Bound چیه؟ 🤔
عملیات‌های IO Bound به کارهایی اشاره دارن که بیشتر زمانشون صرف ورود و خروج داده‌ها میشه. مثلاً وقتی داریم با دیتابیس، فایل‌ها یا شبکه کار می‌کنیم. این نوع عملیات معمولاً منتظر میمونن تا داده‌ها از دیسک یا شبکه بیاد.

مثال‌هایی از IO Bound:
- خوندن و نوشتن در دیتابیس
- ارسال یا دریافت داده‌ها از API
- بارگذاری فایل‌ها

حالا CPU Bound چیه؟ 🧠
عملیات‌های CPU Bound به کارهایی اشاره دارن که بیشتر زمانشون صرف محاسبات سنگین میشه. یعنی برای پردازش و محاسبات نیاز به قدرت پردازشی بالا دارن. در اینجا عملکرد CPU نقش کلیدی رو ایفا می‌کنه.

مثال‌هایی از CPU Bound:
- پردازش تصاویر و ویدئوها
- انجام محاسبات ریاضی پیچیده
- اجرای الگوریتم‌های پیچیده

تفاوت‌های اصلی بین IO Bound و CPU Bound 🔍
1⃣ مدت زمان انتظار:
-عملیات های IO Bound معمولاً منتظر ورود و خروج داده‌ها هستن و زمان زیادی رو صرف این کار می‌کنن.

- عملیات های CPU Bound بیشتر زمانشون رو برای پردازش و محاسبات صرف می‌کنن.

2⃣ تکنیک‌های بهینه‌سازی:
- برای عملیات‌های IO Bound می‌تونی از Async و Threading استفاده کنی تا زمان انتظار رو کاهش بدی.

- برای CPU Bound باید به سراغ Multiprocessing بری تا بتونی از چند هسته CPU به طور همزمان استفاده کنی.

چطور در جنگو با اینها کار کنیم؟ 🚀
- برای IO Bound:
می‌تونی از async و await استفاده کنی تا درخواست‌ها به صورت غیر همزمان انجام بشن و سرعت اپلیکیشن بالا بره.

- برای CPU Bound:
می‌تونی از ماژول concurrent.futures و ProcessPoolExecutor استفاده کنی تا کارهای سنگین رو در چند پروسه اجرا کنی.

جمع‌بندی 🎯
درک تفاوت‌های بین IO Bound و CPU Bound می‌تونه بهت کمک کنه تا اپلیکیشن‌های جنگو رو بهتر بهینه‌سازی کنی. اگه عملیات‌های IO Bound داری، از async استفاده کن و اگر CPU Bound هستن، برو سراغ multiprocessing.

امید وارم مفید بوده باشه :)

#iobound #cpubound #python #django

@ninja_learn_ir

پیکربندی لاگ زدن در جنگو - django logging

در این سری از ویدیوها که به ترفندها و نکته های جنگو میپردازیم، به سراغ لاگ زدن در جنگو رفتیم و کانفیگ ها و شیوه پیکربندی آن را از طریق بررسی و خواندن کد داخلی جنگو، شرح دادیم. در این ویدیو به جای کد نوشتن، بیشتر کد خوندیم که بفهمیم جنگو خودش برای لاگ زدن چگونه کار میکند و ما چگونه میتونیم از آن استفاده کنیم. همچنین امکان django logging را در سرویس های کلودی مانند sentry و APM هم مطرح کردیم. این مفاهیم رو در پروژه مینی ترلو به شکل عملی استفاده میکنیم.


video link: https://youtu.be/LGatKmpL7k8

playlist: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv

#django #logging #microfrontend_ir
〰️〰️〰️〰️〰️
©️ @DjangoEx

خب خب خب Django Channels چیه؟ و چرا من ازش خوشم نمیاد

قبل از اینکه با هم بریم سراغ Django Channels، یه کم درباره WebSocket بگیم که اصلاً بدونیم داریم درباره چی حرف می‌زنیم. خب، WebSocket یه پروتکل که بهت اجازه میده ارتباط دوطرفه و دائمی بین کلاینت و سرور داشته باشی. یعنی چی؟ یعنی مثلاً تو یه اپلیکیشن چت، به جای اینکه هر چند ثانیه یه بار درخواست بفرستی "چیزی جدید اومده؟"، سرور خودش هر وقت یه پیام جدید داشت، بلافاصله می‌فرسته سمتت 🚀.

حالا Django Channels چی میگه؟ 🤔
ـDjango Channels یه ابزار تو اکوسیستم Djangoئه که میاد پشتیبانی از WebSocket، پروتکل‌های real-time و کارای async رو به پروژه‌هات اضافه می‌کنه. به زبان ساده، اگه Django عادی رو یه "خیابون یک‌طرفه" فرض کنیم، Channels میاد این خیابون رو دوطرفه می‌کنه. این یعنی می‌تونی کارایی مثل:

چت real-time 💬

نوتیفیکیشن‌های فوری 🔔

استریم داده (مثل قیمت‌های ارز دیجیتال) 📈

و...

رو خیلی راحت‌تر با Django انجام بدی.

خب پس مشکلش چیه؟ چرا من ازش خوشم نمیاد؟ 🤷‍♂️

از دور که نگاه می‌کنی، Channels خیلی جذاب به نظر میاد، ولی وقتی می‌خوای باهاش کارکنی، مشکلات خودش رو نشون میده:

1⃣ پیچیدگی توی تنظیمات 😵‍💫
ـDjango همیشه به خاطر سادگی معروف بوده، ولی Channels میاد این سادگی رو خراب می‌کنه خیلی خراب میکنه. باید ASGI رو راه بندازی، Redis نصب کنی، routing یاد بگیری، و کلی تنظیمات دیگه انجام بدی. یه پروژه ساده که با Django راحت بود، یهو برات میشه یه جنگل از تنظیمات.

نکته: از Django 4.0 به بعد، پشتیبانی از ASGI مستقیم داخل هسته Django اومده، پس برای پروژه‌های ساده شاید نیاز نباشه کل پروژه رو وابسته به Channels کنی.

2⃣ وابستگی به Redis 🤦‍♂️
یکی از مشکلات بزرگ Channels اینه که برای مدیریت eventها و ارتباط‌ها حتماً نیاز به Redis داره. خب چرا؟ دلیلش اینه که Redis به‌عنوان message broker استفاده میشه تا پیام‌ها بین کلاینت‌ها و سرور مدیریت بشه. ولی اگه پروژه کوچیک باشه، این وابستگی می‌تونه دردسرساز بشه.

جایگزین: می‌تونی از RabbitMQ یا حتی راه‌حل‌های ساده‌تر مثل In-Memory Layers برای پروژه‌های سبک استفاده کنی.

3⃣ محدودیت توی scale کردن 😩
اگه پروژه کوچیک باشه، Channels بد نیست. ولی وقتی تعداد کاربران زیاد میشه و حجم درخواست‌ها بالا میره، Channels سریع از نفس می‌افته. این محدودیت بیشتر به خاطر پیچیدگی WebSocket و محدودیت‌های سرورهای تک رشته ای هست تا خود Channels. برای پروژه‌های بزرگ و real-time محور، ابزارای دیگه‌ای مثل Socket.IO یا FastAPI خیلی بهتر عمل می‌کنن.

4⃣ مشکلات performance 🚨
حتی اگه پروژه خیلی هم بزرگ نباشه، Channels برای real-time پروژه‌های سنگین خوب عمل نمی‌کنه. کارای پیچیده async و ارتباطات real-time می‌تونن سرور رو داغون کنن. البته با تنظیم درست workerها و Redis channel layers می‌تونی بخشی از این مشکلات رو کم کنی، ولی باز هم کار اضافه‌ست.

5⃣ کمبود مستندات و منابع آموزشی درست و حسابی 📚
یکی دیگه از مشکلات اینه که منابع آموزشی کامل و به‌روزی برای Channels خیلی کمه. هر وقت گیر کنی، یا باید بری توی GitHub دنبال issueها، یا دست به دامن دیگران بشی. این باعث میشه زمان زیادی صرف حل مشکلات کنی.

خب حالا راه‌حل چیه؟ 💡
اگه بخوای real-time کار کنی، اینا می‌تونن گزینه‌های بهتری باشن:

ـFastAPI: اگه دنبال سرعت، سادگی و پرفورمنس خوب هستی، FastAPI انتخاب فوق‌العاده‌ایه. با WebSocket خیلی راحت کار می‌کنه و خبری از دردسرای Channels نیست 🚀.

ـSocket.IO: این یکی برای پروژه‌های real-time شاهکاره. خیلی ابزارای متنوع داره و با Node.js هم عالی مچ میشه.


جمع‌بندی 🎯
ـDjango Channels می‌تونه برای پروژه‌های کوچیک و ساده مناسب باشه، ولی اگه بحث scale، پرفورمنس یا راحتی کار مطرح باشه، اصلاً گزینه خوبی نیست. من از پیچیدگی‌ها و محدودیت‌هاش خسته شدم و به جای اون سراغ ابزارای دیگه رفتم.
نظر تو چیه؟ Django Channels تا حالا اذیتت کرده یا ازش خوشت میاد؟ بگو ببینم چی تو ذهنت می‌گذره🧐

#programming #web #django

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

یک مبحثی که خیلی وقت‌ها آدم‌های رو داخل #جنگو گیج میکنه موضوع Aggregation هستش. برای مثال کوئری پایین:

>>> from django.db.models import Avg, Max, Min
>>> Book.objects.aggregate(Avg("price"), Max("price"), Min("price"))
# {'price__avg': 34.35, 'price__max': Decimal('81.20'), 'price__min': Decimal('12.99')}

خب این کوئری مشخصه چه کاری داره انجام میده، همه میتونن بفهمنش مخصوصا وقتی خروجی کوئری رو میبینن، اما اگر ازشون بپرسید خب Aggregation چی هستش هیچ ایده ای ندارن! و این ماجرا از ضعف در دانش SQL سر چشمه میگیره. چون خیلی از آدم‌هایی که دارن #django کار میکنن مستقیم سراغ جنگو اومدن و نرفتن چیزهای دیگه رو مطالعه کنن و یاد بگیرن.

اسم Aggregation داخل ORM جنگو مستقیما از SQL میاد. در SQL یک سری فانکشن وجود داره که بهشون Aggregation functions میگن و کارشون خلاصه سازی اطلاعات:
MIN() - returns the smallest value within the selected column
MAX() - returns the largest value within the selected column
COUNT() - returns the number of rows in a set
SUM() - returns the total sum of a numerical column
AVG() - returns the average value of a numerical column

و خب شما میتونید داخل کوئری‌های SQL ازشون استفاده کنید و دیتا خروجی رو خلاصه سازی کنید و یا یک آمار ازش دربیارید. مثلا میانگین قیمت کتاب‌های تو سال اخیر و ...
یک کوئری مثال برای Aggregation میتونه این باشه:

SELECT AVG(Price) as price_avg FROM Books WHERE puddate='2023-01-01';

خب از اونجایی که ORM جنگو در نهایت قرار کار همین SQL نوشتن برای شما انجام بده و کوئری‌ شمارو به SQL تبدیل کنه شما دقیقا همین کوئری میتونید داخل جنگو به این صورت بنویسید:

>>> from django.db.models import Avg
>>> from datetime import datetime
>>> Books.objects.filter(pubdate=datetime(2023, 1, 1)).aggregate(price_avg=Avg("price"))

میتونید لیست فانکشن‌های Aggregation خود SQL داخل این لینک ببینید و ساپورت جنگو هم میتونید داخل این لینک ببینید.

در نهایت از دانش SQL غافل نباشید و حتما یادش بیگیرید. هرچی بیشتر SQL بدونید زندگی راحت‌تری خواهید داشت.

@TorhamDevCH

می دونستید ممکنه unique_together در آینده توی جنگو منسوخ بشه؟

البته از جنگو 2.2 به بعد داره میگه در آینده ممکنه منسوخ بشه 😁

لینک:
https://docs.djangoproject.com/en/5.2/ref/models/options/#django.db.models.Options.unique_together

خود داکیومنت جنگو گفته بهتره از UniqueConstraint استفاده کنید:

لینک:
https://docs.djangoproject.com/en/5.2/ref/models/constraints/#django.db.models.UniqueConstraint

یه مثال:
فرض کن میخواهیم ترکیب محصول و رنگ فقط یکی باشه، قبلا اینجوری می نوشتیم:

class Meta:
    unique_together = ('product', 'color')

توی UniqueConstraint اینجوریه:

class Meta:
    constraints = [
        models.UniqueConstraint(fields=['product', 'color'], name='unique_product_option')
    ]

تازه میتونیم بگیم در شرایطی خاص این حالت فعال باشه.
خودتون زحمت بکشید condition رو توی لینکی که دادم سرچ کنید.
قابلیت های دیگه ای هم داره، که بازم خودتون...

و من الله التوفیق