✅برای قیمت تخفیفی در فروشگاه جنگو تون چطور عمل می کنید؟

✔️منظورم این چیزی که توی عکس هست.

بعضی شاید بگن یه فیلد قیمت تخفیفی میزارم. میشه، ولی اگه بخوای به 100 محصول تخفیف بدی یا تخفیفش رو برداری باید 100 بار ویرایش کنی.

با بررسی فروشگاه های مختلف متوجه میشید که معمولا قیمت تخفیفی رو بر حسب دسته بندی یا کالکشن یا... میدن

اینجوری همه محصولاتی که عضو اون دسته بندی یا... هست، یکجا قیمت تخفیفی میخورن.

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

✔️تخفیف درصدی، تخفیف ثابت، تخفیف زمان دار و...

✔️این موضوع ارتباطی به جنگو نداره و همه فروشگاه ها، حتی پرستاشاپ هم شامل میشه.

نظرتون رو کامنت کنید یا به @miladhzz بفرستید.

✅پارامتر through توی ارتباط ManyToMany در جنگو

توی مدل های جنگو وقتی یه فیلد ManyToMany ایجاد می کنیم، و Migrate کنیم. خود جنگو یه جدول واسط برای هندل کردن ارتباط چند به چند میسازه.

✔️می تونیم اون جدول واسط رو خودمون کاستوم کنیم (به هر دلیلی)

لذا مثل عکس میتونیم از through استفاده کنیم.

کانال میکرو فرانت اند توی ویدئوی زیر بیشتر توضیحش داده
https://t.me/microfrontend_ir/180

❔سوال: through_fields برای فیلدهای چند به چند کارش چیه؟ و چه استفاده ای داره؟ (توی عکس نیست)

@IIIllIlll زحمت کشیدن یک ریپو خوب برای آموزش او ار ام جنگو ساختن


https://github.com/rz-k/django-orm-tutorial

یکی از اشتباهات رایج و خیلی بد تو دیزاین دیتابیس که من دیدم خیلی انجام میدن اینه که سعی میکنن state یک entity رو با چند boolean ست کنند.
مثلا برای یوزر داریم:
is_active
is_banned
یا شما میتونی برای پردازش یک دیتایی اینطوری هم ذخیره کنی:
is_pending
is_success

اما خیلی پرکتیس بدیه. چرا؟ به ۲ دلیل:
۱. حالت هایی به وجود میاد از ترکیب این boolean ها که رخ دادنش ممکن نیست. مثلا چطوری میشه is_pending=true باشه و is_success هم true باشه؟ حالا هرچی جلوتر برید و تعداد boolean هاتون بیشتر شه این ترکیب هایی که امکان رخ دادنشون وجود نداره خیلی بیشتر میشه. مثلا ۴ تا boolean میشه ۱۶ حالت. آیا واقعا همه ۱۶ حالت رو دارین؟!
۲. راه حل دوم خیلی بهتره! راه حل دوم چیه؟‌استفاده از یک Enum تو دیتابیستون.

PENDING
SUCCESS
FAILED

حالا یک جایی نیازه که ایمیل بزنید اگه این پردازش موفقیت آمیز نبود. خیلی راحت میتونید رو همه حالت ها match case کنید. و در نهایت یک assert never هم قرار بدید.
اینطوری فردا اگه یک state جدید اضافه کنید به اپلیکیشنتون, همه جای کدتون ارور تایپینگ میخورید تا مجبور شید رفتار و ساید افکت state جدید رو تو همه جا هندل کنید.

match state:
   case State.FAILED:
         email_to_user()
   case State.SUCCESS | State.FAILED:
          pass # do nothing
   case _: 
          assert_never(state)

@PyBackendHub

✅دوره (غیر رایگان) فروشگاه اینترنتی با جنگو آپدیت شد.

لینک دوره:
https://www.daneshjooyar.com/project-django/


✔️چند قسمت رایگان از این دوره رو اینجا ببینید:

https://www.aparat.com/v/tga7df6

https://t.me/djangolearn_ir/531
https://t.me/djangolearn_ir/533
https://t.me/djangolearn_ir/573
https://t.me/djangolearn_ir/676
https://t.me/djangolearn_ir/724
https://t.me/djangolearn_ir/889


در صورتی که از لحاظ مالی توانایی پرداخت همه مبلغ دوره رو ندارید، خصوصی پیام بدید.

سلام به همه
اگه دوره بالا رو خریداری کردید
لطفا خصوصی به @miladhzz پیام بدید
تا به کانال اطلاع رسانی دوره (غیر رایگان) فروشگاه اینترنتی با جنگو اضافه تون کنم.

خب خب خب 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

خب خب خب Sentry چیه؟ 🔍

اگه برنامه نویسی میکنی احتمالاً این سناریو برات آشناست:
کلی وقت می‌ذاری، کد می‌نویسی، تست می‌کنی، همه‌چی درست کار می‌کنه. ولی وقتی می‌دی دست کاربر، یهو یه ارور عجیب غریب میاد که اصلاً نمی‌دونی از کجا دراومده اینجاست که Sentry وارد بازی میشه.

ـSentry چیه اصلاً؟
ـSentry یه ابزار خطایاب (Error Tracking) که کمک می‌کنه باگ‌ها و خطاهای پروژه‌ت رو همون لحظه‌ای که اتفاق میفتن، پیدا کنی.
این ابزار نه‌تنها ارورها رو جمع‌آوری می‌کنه، بلکه یه گزارش دقیق و کامل ازشون می‌ده؛ از جزئیات خطا گرفته تا شرایطی که باعث شده ارور پیش بیاد.
فرض کن یه باگ تو اپلیکیشن‌ ته که اصلاً قابل پیش‌بینی نبوده. به‌جای اینکه کاربر بیاد غر بزنه یا خودت بری تو لاگ‌ها دنبال مشکل بگردی، Sentry خودش ارور رو تشخیص می‌ده و گزارشش رو مستقیم برات می‌فرسته.

چرا Sentry محبوبه؟ 🌟
1⃣ گزارش ارور دقیق و کاربردی 🛠️

وقتی یه ارور اتفاق میفته، Sentry دقیقاً بهت میگه مشکل کجاست. جزئیاتی مثل:
فایل و خط کدی که ارور داده
نوع خطا (Exception)
اطلاعات مرورگر یا دستگاه کاربر
وضعیت سرور (مثلاً رم و CPU)
حتی مراحل درخواست کاربر تا لحظه‌ای که ارور رخ داده


2⃣ پشتیبانی از پلتفرم‌های مختلف 📱

هرچی فکرش رو بکنی، Sentry ساپورتش میکنه.
Backend: Python (جنگو، فلاسک و ...)، Node.js
Frontend: React، Vue.js
Mobile: اندروید و iOS
DevOps: Docker، Kubernetes

3⃣ دسته‌بندی ارورها 🗂️

وقتی تعداد ارورها زیاد بشه، Sentry اونا رو گروه‌بندی می‌کنه. مثلاً یه باگ اگه صد بار اتفاق بیفته، همشون رو زیر یه گزارش می‌ذاره که بتونی راحت مدیریت کنی.

4⃣ هشدار و نوتیفیکیشن 🔔

به محض اینکه یه ارور جدید اتفاق بیفته، سریع بهت خبر می‌ده. از ایمیل گرفته تا Slack یا حتی پیامک.

5⃣ـ Release Tracking 🚀

یه قابلیت جالبش اینه که می‌تونی ارورها رو به نسخه‌های پروژت وصل کنی و بفهمی کدوم تغییرات باعث مشکل شده.

6⃣ـPerformance Monitoring ⚡

علاوه بر ارورها، می‌تونی بفهمی اپلیکیشن کجاها کنده.

چطور از Sentry استفاده کنیم؟
ثبت‌نام کن:
تو سایت Sentry.io یه اکانت بساز. نسخه رایگانش برای شروع کافیه.

نصب کن:
ـSDK مخصوص زبان پروژه‌ت رو نصب کن. مثلاً برای Django این دستور کافیه:

 pip install sentry-sdk 

تنظیمش کن:
با چند خط کد ساده Sentry رو به پروژه وصل کن:

import sentry_sdk
sentry_sdk.init(
    dsn="لینک DSN که Sentry می‌ده",
    traces_sample_rate=1.0
)

ارورها رو مدیریت کن:
حالا هر اروری اتفاق بیفته، مستقیم تو داشبورد Sentry میره.

چند نکته مهم:
نسخه رایگان Sentry محدودیت داره (مثلاً تعداد ارورهای ماهانه). برای پروژه‌های بزرگ باید پلن‌های پولیش رو بگیری.
می‌تونی از مستندات رسمی کمک بگیری تا تنظیمات حرفه‌ای‌تر انجام بدی.

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

#programming #python #sentry

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

پیچیدگی و نشانه‌های آن
___________

کتاب A Philosophy of Software Design نوشته‌ی John Ousterhout، میاد و سه نشانه (manifestation) از پیچیدگی در سیستم مطرح میکنه و اینجا میخوام این سه مورد رو باهم مرور کنیم:

- Change Amplification

یک تغییر ساده [در یک عملکرد کلی]، نیازمند تغییر در قسمت‌های مختلفه. دم دستی ترین مثال ممکن که احتمالا در ذهنتون بی‌درنگ نشست، استفاده از یک ثابته (مثل کد رنگ) که در تمام تابع‌ها داره به‌کار برده میشه و هر جا هم یک اسمی داره و ما قراره اون رو عوض کنیم. حالا یک تغییر ساده‌ی ما amplify شد و از یکی شد ۱۰۰ تا (مشابه write amplification در دیتابیس‌ها که گاهی یک رایت ساده، منجر به چسبیدن IO به سقف میشه).

- Cognitive Load

چقدر یک توسعه‌دهنده نیازه که [راجع‌به سیستم] بدونه برای این که یک تسک رو به سرانجام برسونه. هرچقدر این «دونستن» بیشتر لازم باشه، به طبع نیازمنده تا زمان بیشتری رو صرف یادگیری کنه تا تسک مذکور رو انجام بده و این تعدد نیاز به دانستن‌ها، ریسک به وجود اومدن باگ رو بیشترو بیشتر می‌کنه.

در این مورد، گریزی هم به ماجرای تعداد خط‌ها میشه زد. بعضی‌ طراحان سیستم فکر میکنند که تعداد خط کمتر منجر به کاهش پیچیدگی سیستم میشه.
شاید اینطور باشه که خوندن یک کلاس عریض و طویل بسیار وحشتناکه، اما به تجربه، هیچ‌چیز ترسناک تر از خوندن کد‌های کوتاهی نیست که سراسر پر شدند از trick و magic‌هایی که بدون دانش قبلی هیچ ایده‌ای نخواهیم داشت راجع‌به این که این چند خط چطور کار می‌کنند.

کاهش تعداد خط با خیال کاهش پیچیدگی در نهایت می‌تونه به افزایش cognitive load منجر بشه و مارو از اون رویای شیرین، به وسط کابوس کد‌بیس پیچیده پرتاب کنه.

- Unknown unknowns

بدترین بین این سه اما، ناشناخته‌های ناشناخته‌ست. به این معنی که ما ندونیم کدوم قسمت از کد باید تغییر کنه تا تسک ما انجام بشه.

unknown unknown means that there is something you need to know, but there is no way for you to find out what it is, or even whether there is an issue.

در این حالت، برای ما روشن نخواهد بود که چه کار باید بکنیم، یا اونچه که قصد انجامشو داریم اصلا کاراست یا نه.

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


پی‌نوشت:
- از عباس عزیز واقعا ممنونم بابت معرفی کتاب.

- کتاب رو دو روزه که شروع کردم و دلم میخواد تیکه‌هاییش که برام جالبه یا ممکنه برای شما جالب باشه رو چه با نقل و قول مستقیم، چه غیرمستقیم اینجا هم بنویسم.

- بجز تعریف سیستم پیچیده که به شکل تعریف نشانه‌هاش بالاتر ازش حرف زدیم و مختص به سیستم‌های نرم‌افزاری بود، بد نیست یک گریزی بزنیم به کتاب Melanie Mitchell
با عنوان «سیری در نظریه پیچیدگی» (عنوان اصلی کتاب، Complexity: A Guided Tour) که اون هم کتابیه خوندنی و توصیه‌ش میکنیم. در انتهای فصل اول کتاب، سیستم پیچیده رو به دو شکل تعریف میکنه:

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

و تعریف دوم:

سیستمی که رفتار‌های نا‌بدیهی (nontrival) و نوظهور و خود-سازمان را به‌نمایش میگذارد.

که فکر میکنم تعریف دوم، بیشتر با شرح نشانه‌هایی که از یک سیستم نرم‌افزاری دیدیم هم‌سو باشه.

گردونه شانس رو آزمایش کنید

الان دیدم یکی دوره من رو با 92 درصد تخفیف خریده 😳

توی صفحه اول دانشجویار نوار جشنواره بالای سایتشون

‏یکی از پرطرفدارترین آموزش‌های دکتر کلامی در فرادرس، آموزش اصول و مبانی برنامه‌نویسی است که به صورت رایگان در دسترس است و به طور متوسط، در هر ماه بیش از ۴۰۰۰ نفر درخواست دسترسی به آن را ثبت می‌کنند.

🔗لینک آموزش:
https://faradars.org/courses/fvrprg101-programming-basics-concepts

‏این آموزش در کمتر از ۳ ساعت، هر آنچه را که برای ورود به دنیای برنامه‌نویسی لازم است، یاد می‌دهد. آموزش اصول و مبانی برنامه‌نویسی، در واقع درس شماره صفر سایر آموزش‌های برنامه‌نویسی است و دانستن مفاهیم ارائه شده در آن، در یادگیری بهتر هر زبان برنامه‌نویسی دلخواه، کمک‌کننده است.

دکتر کلامی هریس

همونطور که میدونین HTTP میاد روی TCP سوار میشه و توسط اون داده‌ رو میفرسته، عملا پروتکل http چیزی جز یه مشت قوانین روی چند خط string نیست. اکثرا وظایفش توسط Tcp پیاده سازی شده و ما فکر میکنیم که Http داره نقشش رو خوب بازی میکنه.

حالا دوتا از این نقش هایی که توسط Tcp بازی میشن چی هستن؟
- اطمینان از تحویل داده: توی Http ما گارانتی اینو از پروتکل میگیریم که داده ها صحیح و سالم تحویل داده بشن
- ترتیب صحیح داده ها: توی شبکه ممکنه بسته‌ها به صورت ناهمزمان و با ترتیبی غیر از ترتیب ارسال شده دریافت بشن، اما TCP این تضمین رو میده که داده‌ها توی مقصد به ترتیب ارسال مرتب و بازسازی بشن. خود HTTP هم از این ویژگی استفاده میکنه و نیازی به مدیریت ترتیب داده‌ها نداره.

به طور کلی، خیلی از ویژگی ‌هایی که ما از HTTP میدونیم در حقیقت توسط TCP پیاده‌سازی میشن و HTTP بیشتر به عنوان یه لایه برای تعریف اون قوانینی که بالا گفتم برای تبادل این داده ها و نوع محتوای ارسال شده عمل میکنه.

همه ی اینارو گفتم که بگم تا حالا به این فکر کردین که بیاییم Http رو روی UDP پیاده سازی کنیم چی میشه؟ میشه پروتکل Http/3 که بهش میگن QUIC حالا چالشاش چیه؟ پستای بعدی میگم

@knowpow

SQL Cheatsheet

〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir

توی این ویدئو تغییراتی توی کد دادم، تا وقتی کاربر لاگین شد، آیتم های سبد خریدی که توی دیتابیس داره، لود بشن و توی سبد خریدش مشاهده شون کنه.

اگه کاربر لاگین نکرده باشه و چندتا آیتم هم توی سبد خریدش داشته باشه (همون سبد خرید سشنی) ، بعد از لاگین، ابتدا آیتم های سبد خرید دیتابیسی لود میشن، سپس آیتم های سبد خرید سشنی توی دیتابیس ذخیره میشن.

✅این ویدئو بخشی از آپدیت جدید آموزش ساخت فروشگاه اینترنتی است.

لینک همین ویدئو در آپارت:
https://www.aparat.com/v/pneon5r
لینک یوتیوب:
https://youtu.be/w9_PnBoG1jU

✔️لینک سورس کد کامل دوره فروشگاه اینترنتی با جنگو:
https://github.com/miladhzz/daneshjooyar_shop2/

خوشحال میشم ریپو رو نقد کنید.

#Quick

داشتم پروژه django شرکت رو می‌خوندم یک مشکل داریم سر بعضی endpointها و برخی تسک‌ها.
اولین کاری کردم این بوده که یک سری دیتا تست با faker بهش دادم مثه loadtest ولی بدون ابزار و بعد هم profiling گرفتم و ذخیره کردم.
چیز جالبی که دیدم؛ پروژه موقع کار کردن با redis به مشکل میخورد.
ولی redis منابعش بیشتر از حد مورد نیازش بود.

حجم دیتاهای تست رو کم کردم و مشکل حل شد؛ توی چندتا تست مختلف که زدم دیدم مسئله و مشگل از سمت پیکج redis هست توی پایتون و راهکار ساده رو هم خود redis داده (هرچند من برعکس بهش رسیدم)

$ pip install "redis[hiredis]"

بجای اینکه برای parse کردن دیتا از python استفاده کنه وقتی hiredis رو نصب کنید از C استفاده می‌کنه (بنچمارکاش هم توی گیت‌هاب hiredis هست ببینید)

مشکل خیلی ساده حل شد؛ ولی برای این حل ساده خیلی زمان و درک profiling لازم بود.

اهمیت profiling

این تیتر هم جالب بود 9 الگورتیمی که بر دنیای ما حکمرانی می‌کنند.

@Linuxor

این سوال ع stackoverflow برای منم سوال شده بود (البته عکسی که گذاشتم یه پاسخه)

Django 'Sites' Model - what is and why is 'SITE_ID = 1'?
لینک سوال:
https://stackoverflow.com/questions/25468676/django-sites-model-what-is-and-why-is-site-id-1

عکسی که گذاشتم اشاره کرده که تا جنگو 1.4 فریمورک sites کارش چیز دیگه ای بوده. ایشویی که اشاره کرده رو ببینید.

✔️راستی اون SITE_ID به خاطر این مقدارش 1 باید باشه، چون وقتی sites رو به installed_app اضافه میکنیم باید مایگریت کنیم و یه رکورد به جدول site اضافه میکنه با مقدار example.com و آیدی ش هم 1 هست.

و خب مسلما قابل تغییره