Django — batteries included, ORM, admin আর MVT

১ · Django কী — নিউজরুমের তাড়া থেকে “batteries included”

এতক্ষণ আমরা বাজারঘর বানিয়েছি JavaScript-এর জগতে: React সামনে, Express আর Prisma পেছনে। প্রতিটি কাজের জন্য একটি করে package বেছে নিয়েছি: validation-এ Zod, login-এ session store, ORM-এ Prisma. এই পর্বে একই দোকানের একটি ছোট অংশ বানাব Python-এর একটি বহুল পরিচিত web framework Django দিয়ে। Python ভাষাটি নিজে শিখতে চাইলে আমাদের Python কোর্স আছে। এখানে ভাষা নয়, framework-এর চিন্তা দেখব।

নিউজরুমের এই উৎস Django-র চরিত্র বোঝায়। সংবাদপত্রে সম্পাদকরা প্রতিদিন লেখা যোগ করেন, তাই admin পাতা দরকার। অনেক ধরনের কনটেন্ট, তাই শক্তিশালী ORM দরকার। Deadline আছে, তাই সব একসাথে থাকা দরকার। অনেকের মতে আজও Django সবচেয়ে উজ্জ্বল এই ধরনের কাজে।

Project আর app

Django-তে দুটি শব্দ শুরুতেই গুলিয়ে যায়। Project হলো পুরো ওয়েবসাইট: settings, মূল URL তালিকা আর server-এর প্রবেশদ্বার। App হলো একটি নির্দিষ্ট কাজের অংশ, যেমন shop, blog বা accounts, যার নিজের model, view আর template থাকে। একটি project-এ অনেক app থাকে। Admin, auth আর session-ও আসলে Django-র নিজের app. একটি বড় শপিং মলকে project ভাবুন, আর প্রতিটি দোকানকে app.

সত্যিকারের project · Django 6.1.2, Python 3.14.4, SQLite · তৈরি django-admin startproject bazarghar আর python manage.py startapp shop দিয়ে · ~/bazarghar

bazarghar/
├── manage.py              # কমান্ডের দরজা: runserver, migrate, test …
├── db.sqlite3
├── bazarghar/             # project: সাইটের সাধারণ অংশ
│   ├── settings.py        # INSTALLED_APPS, MIDDLEWARE, DATABASES …
│   ├── urls.py            # মূল URL তালিকা
│   ├── wsgi.py / asgi.py  # server-এর প্রবেশদ্বার
└── shop/                  # app: বাজারঘরের পণ্য
    ├── models.py  views.py  urls.py  admin.py  tests.py
    ├── migrations/0001_initial.py
    └── templates/shop/products.html

লেখার সময়ে PyPI-তে Django-র সর্বশেষ সংস্করণ 6.1.2, যা Python 3.12 বা তার নতুন চায়। Django সাধারণত প্রায় আট মাস পরপর একটি feature release দেয়, আর কয়েক সংস্করণ পরপর একটি দীর্ঘমেয়াদি সহায়তার (LTS) সংস্করণ। লেখার সময়ে সর্বশেষ LTS ছিল 5.2. নতুন project-এ কোনটি নেবেন, তা Django-র ওয়েবসাইটের “supported versions” তালিকা দেখে ঠিক করুন।

২ · MVT — Express আর React-এর চোখে

পর্ব ০৪-এ MVC আর MVT নাম হিসেবে দেখেছেন। এবার কাজে দেখি। Django-র তিন ভাগ: Model (ডেটা আর তার নিয়ম), View (একটি URL-এর জন্য Python function, যা ঠিক করে কোন ডেটা দেখানো হবে), আর Template (সেই ডেটা দেখতে কেমন হবে)। তাহলে controller কোথায়? Django-র FAQ নিজেই বলে, তাদের ব্যাখ্যায় controller সম্ভবত framework নিজে: যে যন্ত্র URL দেখে request-কে সঠিক view-তে পাঠায়।

লক্ষ করুন, Django-র template server-এ চলে, পাতা তৈরি করে পাঠায়। এটি পর্ব ০৩-এর (Rendering-এর মানচিত্র) SSR, React-এর মতো browser-এ UI ধরে রাখা নয়। অনেক দল তাই Django-কে শুধু API হিসেবে চালায়, আর সামনে React বা Next.js রাখে। দুটি পথই প্রচলিত।

নিচে বাজারঘরের /products/ পাতার একটি request ধাপে ধাপে দেখুন। প্রতিটি কোড আর SQL আমাদের আসল project থেকে।

GET /products/ HTTP/1.1
Host: 127.0.0.1:8124

SecurityMiddleware
SessionMiddleware       # cookie → request.session
CommonMiddleware
CsrfViewMiddleware      # POST হলে token যাচাই
AuthenticationMiddleware # request.user
MessageMiddleware
XFrameOptionsMiddleware

# bazarghar/urls.py
path('admin/', admin.site.urls)       ✗
path('', include('shop.urls'))        → ভেতরে
# shop/urls.py
path('products/', views.product_page) ✓

def product_page(request):
    products = (Product.objects
        .select_related('category')
        .filter(stock__gt=0).order_by('price'))
    return render(request, 'shop/products.html',
                  {'products': products})

SELECT "shop_product"."id", …, "shop_category"."name"
FROM "shop_product"
INNER JOIN "shop_category"
  ON ("shop_product"."category_id" = "shop_category"."id")
WHERE "shop_product"."stock" > 0
ORDER BY "shop_product"."price" ASC

<h1>বাজারঘর</h1>
<ul>
    <li>Turmeric 200g (Spices): 95 টাকা</li>
    <li>Red Chilli 200g (Spices): 110 টাকা</li>
    …
</ul>

"GET /products/ HTTP/1.1" 200
# middleware উল্টো ক্রমে response-এ header বসায়,
# যেমন X-Frame-Options

৩ · Model আর ORM — অলস QuerySet

Django-র ORM Active Record ধাঁচের: প্রতিটি model class একটি টেবিল, প্রতিটি object একটি সারি, আর object নিজেই save() করতে পারে। পর্ব ৩৮-এ (ORM-এর ধারণা) এই ধাঁচ আর Prisma-র পার্থক্য দেখেছেন। বাজারঘরের দুটি model:

from django.db import models

class Category(models.Model):
    name = models.CharField(max_length=80, unique=True)

class Product(models.Model):
    category = models.ForeignKey(Category, on_delete=models.PROTECT,
                                 related_name='products')
    name = models.CharField(max_length=120)
    price = models.PositiveIntegerField()          # টাকা, পূর্ণসংখ্যা
    stock = models.PositiveIntegerField(default=0)

লক্ষ করুন: id লিখিনি, Django নিজে দেয়। PositiveIntegerField ডেটাবেসে একটি CHECK নিয়মও বসায়, সেটি পরের অংশে migration-এর SQL-এ দেখবেন। on_delete=models.PROTECT মানে পণ্য থাকা অবস্থায় ক্যাটাগরি মোছা যাবে না। এই ছোট lab-এ সরলতার জন্য দাম পূর্ণ টাকায় রাখা হয়েছে; আসল দোকানে পর্ব ৩২-এর মতো পয়সায় পূর্ণসংখ্যা রাখাই নিরাপদ।

QuerySet লিখলেই SQL যায় না

Product.objects.filter(...) যা ফেরত দেয় তার নাম QuerySet. এটি ফল নয়, একটি প্রশ্নের খসড়া। চায়ের দোকানে অর্ডারের স্লিপ লেখার মতো: যতক্ষণ স্লিপ রান্নাঘরে না যায়, চুলা জ্বলে না। আপনি স্লিপে “চিনি কম”, “দুধ বেশি” যোগ করতে পারেন, প্রতিবার নতুন স্লিপ হয়। একে বলে lazy evaluation. আমাদের project-এ চালানো একটি ছোট script:

সত্যিকারের run · Django 6.1.2 · CaptureQueriesContext দিয়ে query গোনা · SQL লাইন ছাঁটা নয়

qs  = Product.objects.filter(stock__gt=0).order_by('price')
qs2 = qs.filter(category__name='Tea')

after filter(): 0 queries
SQL: SELECT "shop_product"."id", "shop_product"."category_id", "shop_product"."name", "shop_product"."price", "shop_product"."stock" FROM "shop_product" INNER JOIN "shop_category" ON ("shop_product"."category_id" = "shop_category"."id") WHERE ("shop_product"."stock" > 0 AND "shop_category"."name" = Tea) ORDER BY "shop_product"."price" ASC
after iterating: 1 queries ['Green Tea 100g', 'Sylhet Tea 400g']
iterate same qs again: 1 queries
count(): 5 -> 2 queries

চারটি জিনিস পড়ুন। প্রথম, দুটি filter()-এর পরেও ০টি query. দ্বিতীয়, category__name লিখতেই ORM নিজে JOIN বসিয়েছে; দুই underscore (__) মানে সম্পর্ক পেরিয়ে যাওয়া। তৃতীয়, একই qs2-তে দ্বিতীয়বার লুপ চালালে নতুন query যায়নি, কারণ QuerySet নিজের ভেতরে ফল জমা (cache) রাখে। চতুর্থ, আগে না চালানো qs-এর count() একটি আলাদা COUNT query পাঠিয়েছে।

এবার মডেলটি নিজে চালিয়ে দেখুন। নিচের শেখানোর মডেলটি আসল Django নয়। এটি শুধু Python-এর sqlite3 দিয়ে একই ধারণা দেখায়: filter() নতুন খসড়া ফেরত দেয়, আর লুপ শুরু হলে তবেই SQL যায়।

# শেখানোর মডেল: Django-র lazy QuerySet-এর ধারণা, আসল Django নয়
import sqlite3
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE product (name TEXT, price INT, stock INT)")
db.executemany("INSERT INTO product VALUES (?, ?, ?)", [
    ("Miniket Rice 5kg", 420, 30), ("Soybean Oil 1L", 190, 0),
    ("Sylhet Tea 400g", 260, 18), ("Turmeric 200g", 95, 25)])
sent = []
db.set_trace_callback(sent.append)   # ডেটাবেসে যাওয়া প্রতিটি SQL জমা

class QuerySet:
    def __init__(self, where=(), order=None):
        self.where, self.order, self.cache = list(where), order, None
    def filter(self, cond, value):     # নতুন QuerySet, SQL চলে না
        return QuerySet(self.where + [(cond, value)], self.order)
    def order_by(self, col):
        return QuerySet(self.where, col)
    def sql(self):
        s = "SELECT name, price FROM product"
        if self.where:
            s += " WHERE " + " AND ".join(c for c, _ in self.where)
        return s + (f" ORDER BY {self.order}" if self.order else "")
    def __iter__(self):                # এখানেই প্রথম SQL চলে
        if self.cache is None:
            params = [v for _, v in self.where]
            self.cache = db.execute(self.sql(), params).fetchall()
        return iter(self.cache)

qs = QuerySet().filter("stock > ?", 0).filter("price < ?", 300).order_by("price")
print("built:", qs.sql())
print("SQL sent so far:", len(sent))
print("rows:", list(qs))
print("SQL sent so far:", len(sent))
list(qs)
print("after 2nd loop:", len(sent))

৪ · N+1: select_related আর prefetch_related

Lazy আচরণের উল্টো পিঠ আছে। Prisma সম্পর্ক না চাইলে আনে না, তাই পর্ব ৪২-এ (N+1 সমস্যা) লুপটি আমাদের হাতে লিখতে হয়েছিল। Django-তে p.category.name লিখলেই ORM চুপচাপ SQL পাঠায়। কোড দেখে বোঝার উপায় নেই। ফলে N+1 এখানে আরও সহজে লুকায়। বাজারঘরের seed command এটি মেপেছে:

reset_queries()
for p in Product.objects.all():
    p.category.name
self.stdout.write(f'Without select_related: {len(connection.queries)} queries')

reset_queries()
for p in Product.objects.select_related('category'):
    p.category.name
self.stdout.write(f'With select_related: {len(connection.queries)} queries')

সত্যিকারের run · python manage.py seed · ৩টি ক্যাটাগরি, ৬টি পণ্য · DEBUG=True, তাই connection.queries ভরে

$ python manage.py seed
Seeded 3 categories, 6 products
Without select_related: 7 queries
With select_related: 1 queries
  SELECT "shop_product"."id", "shop_product"."category_id", "shop_product"."name", "shop_product"."price", "shop_product"."stock", "shop_category"."id", "shop_category"."name" FROM "shop_product" INNER JOIN "shop_category" ON ("shop_product"."category_id" = "shop_category"."id")

1for p in Product.objects.all():2    p.category.name   # লুকানো SQL34for p in Product.objects.select_related('category'):5    p.category.name   # SQL নেই

কোনটি কখন

select_related SQL JOIN লেখে, তাই এটি শুধু “একটির দিকে” যাওয়া সম্পর্কে চলে: ForeignKey আর OneToOne. “অনেকের দিকে” (একটি ক্যাটাগরির সব পণ্য, many-to-many) JOIN করলে সারি গুণ হয়ে যায়। সেখানে prefetch_related: আগে মূল তালিকা, তারপর সব id জুড়ে একটি IN query, আর জোড়া লাগানো Python-এ। আমাদের run:

সত্যিকারের run · একই project, ৩টি ক্যাটাগরি

categories loop, no prefetch: 4 queries
with prefetch_related: 2 queries
  2nd SQL: SELECT "shop_product"."id", "shop_product"."category_id", "shop_product"."name", "shop_product"."price", "shop_product"."stock" FROM "shop_product" WHERE "shop_product"."category_id" IN (1, 2, 3)

৩টি ক্যাটাগরিতে লুপে ১ + ৩ = ৪, prefetch_related-এ ২. সূত্রটি Prisma-র include-এর query strategy-র মতোই। নিচের কোডে তিনটি পথ একসাথে গুনে দেখুন। এটি আসল Django নয়, সাধারণ sqlite3; ORM ভেতরে যে SQL লেখে, সেগুলো হাতে লেখা।

# N+1 গোনা: sqlite3-এর trace callback প্রতিটি SQL ধরে
import sqlite3
db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE category (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE product (id INTEGER PRIMARY KEY, name TEXT, category_id INT);
INSERT INTO category VALUES (1,'Grocery'),(2,'Tea'),(3,'Spices');
INSERT INTO product VALUES (1,'Miniket Rice',1),(2,'Soybean Oil',1),
 (3,'Sylhet Tea',2),(4,'Green Tea',2),(5,'Turmeric',3),(6,'Red Chilli',3);
""")
log = []
db.set_trace_callback(log.append)

# ১) lazy পথ: প্রতিটি product.category-র জন্য আলাদা SQL
log.clear()
for pid, name, cid in db.execute("SELECT id, name, category_id FROM product"):
    cat = db.execute("SELECT name FROM category WHERE id = ?", (cid,)).fetchone()[0]
print("lazy loop:", len(log), "queries")

# ২) select_related-এর মতো: একটি INNER JOIN
log.clear()
rows = db.execute("""SELECT p.name, c.name FROM product p
                     INNER JOIN category c ON p.category_id = c.id""").fetchall()
print("join     :", len(log), "query,", len(rows), "rows")
print(rows[:2])

# ৩) prefetch_related-এর মতো: ২টি SQL, দ্বিতীয়টি IN দিয়ে
log.clear()
cats = db.execute("SELECT id, name FROM category").fetchall()
ids = [c[0] for c in cats]
marks = ",".join("?" * len(ids))
prods = db.execute(f"SELECT name, category_id FROM product WHERE category_id IN ({marks})", ids).fetchall()
print("prefetch :", len(log), "queries")
print(log[-1])

Numerical: ধরুন ডেটাবেস আলাদা মেশিনে, প্রতিটি query-র round trip (RTT) ২ ms, আর পাতায় ৫০টি পণ্য, প্রতিটিতে দুটি ForeignKey (ক্যাটাগরি, বিক্রেতা)। Lazy পথে ১ + ২ × ৫০ = ১০১টি query, শুধু অপেক্ষায় ১০১ × ২ = ২০২ ms. select_related('category', 'seller')-এ ১টি query, ২ ms. দুটিই prefetch_related দিয়ে করলে ৩টি query, ৬ ms. পাতায় পণ্য বাড়লে প্রথমটির খরচ বাড়ে, বাকি দুটির নয়।

৫ · Migration — model বদলালে কী ঘটে

পর্ব ৪০-এ (Migration আর seed) Prisma Migrate দেখেছেন। Django-তেও একই চিন্তা: model হলো কাঙ্ক্ষিত অবস্থা, migration ফাইল হলো সেখানে পৌঁছানোর ধাপ। দুটি কমান্ড: makemigrations model আর আগের migration-এর তুলনা করে নতুন ফাইল লেখে, migrate সেই ফাইল ডেটাবেসে চালায়। মাঝে sqlmigrate দিয়ে আসল SQL পড়ে নেওয়া ভালো অভ্যাস।

সত্যিকারের run · প্রথম migration · Django-র নিজের app-গুলোর লাইন ছাঁটা

$ python manage.py makemigrations shop
Migrations for 'shop':
  shop\migrations\0001_initial.py
    + Create model Category
    + Create model Product

$ python manage.py sqlmigrate shop 0001
BEGIN;
CREATE TABLE "shop_category" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(80) NOT NULL UNIQUE);
CREATE TABLE "shop_product" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(120) NOT NULL, "price" integer unsigned NOT NULL CHECK ("price" >= 0), "stock" integer unsigned NOT NULL CHECK ("stock" >= 0), "category_id" bigint NOT NULL REFERENCES "shop_category" ("id") DEFERRABLE INITIALLY DEFERRED);
CREATE INDEX "shop_product_category_id_14d7eea8" ON "shop_product" ("category_id");
COMMIT;

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions, shop
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  …
  Applying sessions.0001_initial... OK
  Applying shop.0001_initial... OK

দুটি জিনিস চোখে রাখুন। প্রথমত, Django foreign key-তে নিজে থেকে index (shop_product_category_id_14d7eea8) বানিয়েছে, যা পর্ব ৪২-এ PostgreSQL-এ Prisma দেয়নি। দ্বিতীয়ত, প্রথম migrate-এ admin, auth, session-এর টেবিলও তৈরি হলো। Batteries এই টেবিলগুলোতেই থাকে। এবার পণ্যে একটি নতুন field যোগ করি: “বিশেষ পণ্য” চিহ্ন।

class Product(models.Model):
    …
    stock = models.PositiveIntegerField(default=0)
    is_featured = models.BooleanField(default=False)

$ python manage.py makemigrations shop
Migrations for 'shop':
  shop\migrations\0002_product_is_featured.py
    + Add field is_featured to product

class Migration(migrations.Migration):
    dependencies = [('shop', '0001_initial')]
    operations = [
        migrations.AddField(
            model_name='product', name='is_featured',
            field=models.BooleanField(default=False)),
    ]

CREATE TABLE "new__shop_product" (…, "is_featured" bool NOT NULL, …);
INSERT INTO "new__shop_product" (…, "is_featured")
  SELECT …, 0 FROM "shop_product";
DROP TABLE "shop_product";
ALTER TABLE "new__shop_product" RENAME TO "shop_product";
CREATE INDEX "shop_product_category_id_14d7eea8" …;

$ python manage.py migrate shop
Running migrations:
  Applying shop.0002_product_is_featured... OK

$ python manage.py showmigrations shop
shop
 [X] 0001_initial
 [X] 0002_product_is_featured

৬ · View, URLconf আর form

URLconf: রিকশার রুট-তালিকা

URLconf হলো urlpatterns নামের একটি তালিকা। প্রতিটি path() একটি URL নকশা আর একটি view জোড়ে। <int:pk>-এর মতো অংশকে বলে path converter: এটি মান মিলিয়ে দেখে, Python int-এ বদলে view-কে দেয়। Express-এর :id সবসময় string দেয়; এখানে converter-এর কারণে /api/products/abc/ view পর্যন্ত পৌঁছায়ই না, সরাসরি 404.

from django.urls import path
from . import views

urlpatterns = [
    path('products/', views.product_page, name='products'),
    path('products/cbv/', views.ProductList.as_view(), name='products-cbv'),
    path('products/new/', views.ProductCreate.as_view(), name='product-new'),
    path('api/products/<int:pk>/', views.product_api, name='product-api'),
]

name= দিয়ে URL-এর একটি নাম থাকে। Template-এ {% url 'products' %} বা Python-এ reverse('products') লিখলে URL তৈরি হয়, তাই পথ বদলালে সব লিংক নিজে বদলায়। নিচের শেখানোর মডেলটি path()-এর মিলানোর নিয়মটি অল্প কথায় দেখায়।

# শেখানোর মডেল: Django path() converter-এর মতো ছোট URL মিলানো
import re

CONVERTERS = {"int": r"[0-9]+", "str": r"[^/]+", "slug": r"[-a-zA-Z0-9_]+"}
CAST = {"int": int, "str": str, "slug": str}

def compile_route(route):
    parts, kinds = [], {}
    for piece in re.split(r"(<[^>]+>)", route):
        if piece.startswith("<"):
            kind, name = piece[1:-1].split(":")
            kinds[name] = kind
            parts.append(f"(?P<{name}>{CONVERTERS[kind]})")
        else:
            parts.append(re.escape(piece))
    return re.compile("^" + "".join(parts) + "$"), kinds

urlpatterns = [
    ("products/", "product_page"),
    ("products/<int:pk>/", "product_detail"),
    ("category/<slug:slug>/", "category_page"),
]
compiled = [(compile_route(r), view) for r, view in urlpatterns]

def resolve(path):
    for (rx, kinds), view in compiled:       # ওপর থেকে নিচে, প্রথম মিলেই থামে
        m = rx.match(path)
        if m:
            kwargs = {k: CAST[kinds[k]](v) for k, v in m.groupdict().items()}
            return view, kwargs
    return "404", {}

for p in ["products/", "products/7/", "products/abc/", "category/tea/", "products/7"]:
    print(f"{p:16} ->", resolve(p))

Function view আর class-based view

View দুই রকম। Function view একটি সাধারণ function: request নেয়, HttpResponse ফেরত দেয়। Class-based view (CBV) হলো তৈরি class, যার ভেতরে সাধারণ কাজের নকশা আগে থেকে লেখা: তালিকা দেখানো (ListView), একটি দেখানো (DetailView), আর form দিয়ে নতুন সারি তৈরির CreateView ইত্যাদি। আপনি শুধু কয়েকটি attribute বদলান।

def product_api(request, pk):
    p = get_object_or_404(Product.objects.select_related('category'), pk=pk)
    return JsonResponse({'id': p.pk, 'name': p.name,
                         'price': p.price, 'category': p.category.name})

class ProductList(ListView):
    queryset = (Product.objects.select_related('category')
                .filter(stock__gt=0).order_by('price'))
    template_name = 'shop/products.html'
    context_object_name = 'products'

class ProductCreate(CreateView):
    model = Product
    fields = ['category', 'name', 'price', 'stock']   # allowlist
    template_name = 'shop/product_form.html'
    success_url = '/products/'

সত্যিকারের run · runserver 127.0.0.1 · curl

$ curl -s /api/products/1/
{"id": 1, "name": "Miniket Rice 5kg", "price": 420, "category": "Grocery"}
$ curl -s -o /dev/null -w "%{http_code}" /api/products/999/
404
$ curl -s -o /dev/null -w "%{http_code}" /api/products/abc/
404

Function view পড়া সহজ, সব কিছু চোখের সামনে। CBV কম লাইনে বেশি কাজ করে, কিন্তু আসল আচরণ লুকিয়ে থাকে কয়েক স্তর inheritance-এর ভেতরে। Community-তে এ নিয়ে মতভেদ পুরোনো। অনেক দল সাধারণ CRUD-এ CBV আর বিশেষ নিয়মে function view মিশিয়ে ব্যবহার করে। নতুন হলে function view দিয়ে শুরু করাই সহজ।

Form আর validation

পর্ব ২৭-এ (Request যাচাই) Zod দিয়ে schema লিখে ইনপুট যাচাই করেছেন। Django-তে ModelForm model থেকেই নিয়ম পড়ে নেয়: ফাঁকা নাম চলবে না, দাম ঋণাত্মক হবে না, ক্যাটাগরি অবশ্যই থাকতে হবে। fields তালিকাটি একটি allowlist: তালিকার বাইরের ঘর পাঠালে চুপচাপ বাদ পড়ে, তাই কেউ is_admin=1 জুড়ে দিলেও লাভ নেই (mass assignment থেকে সুরক্ষা)।

সত্যিকারের run · ProductForm(data={'category': '999', 'name': '', 'price': '-5', 'stock': 'abc', 'is_admin': '1'})

is_valid: False
  category -> ['Select a valid choice. That choice is not one of the available choices.']
  name -> ['This field is required.']
  price -> ['Ensure this value is greater than or equal to 0.']
  stock -> ['Enter a whole number.']

চারটি ঘরেই আলাদা বার্তা, আর ক্যাটাগরি 999 ডেটাবেসে নেই, সেটিও form নিজে যাচাই করেছে। is_admin নিয়ে কোনো কথাই নেই, কারণ form ঘরটি চেনেই না। Browser থেকে ProductCreate-এ ভুল ডেটা পাঠালে একই বার্তা পাতায় ফেরে, status 200; সঠিক ডেটায় 302 দিয়ে তালিকায় পাঠায়:

সত্যিকারের run · /products/new/-এ CSRF token-সহ POST · HTML ছাঁটা

--- name ফাঁকা, price -5
errorlist" id="id_name_error"><li>This field is required.
errorlist" id="id_price_error"><li>Ensure this value is greater than or equal to 0.
200
--- সঠিক ডেটা: Darjeeling Tea 100g, 240
302 http://127.0.0.1:8167/products/

৭ · Template আর autoescape — string literal-এর ফাঁদ

Django-র template ভাষায় দুই রকম চিহ্ন: {{ product.name }} একটি মান বসায়, {% for %} বা {% if %} নিয়ম চালায়। এটি ইচ্ছা করে সীমিত: template-এ যেকোনো Python চালানো যায় না, যাতে ডিজাইনার নিরাপদে HTML লিখতে পারেন।

<h1>বাজারঘর</h1>
<ul>
{% for product in products %}
    <li>{{ product.name }} ({{ product.category.name }}): {{ product.price }} টাকা</li>
{% empty %}
    <li>কোনো পণ্য নেই</li>
{% endfor %}
</ul>
<p>{{ note }}</p>

সবচেয়ে গুরুত্বপূর্ণ ডিফল্টটি হলো autoescape: প্রতিটি variable-এর <, >, &, উদ্ধৃতিচিহ্ন HTML-এ নিরাপদ রূপে (escaping) বসে। React-এর JSX-ও {name}-কে একইভাবে escape করে। দুই জায়গায় নিরাপত্তা ভাঙে: আপনি নিজে |safe বা mark_safe() লিখলে, আর একটি কম পরিচিত জায়গায়: template-এ সরাসরি লেখা string literal. Django-র docs অনুযায়ী literal-গুলো escape ছাড়াই বসে, যেন আগে থেকেই safe. আমাদের lab-এ একই <script> তিনভাবে চালানো হলো:

সত্যিকারের run · Django 6.1.2-এর Template(...).render()

variable : <p>&lt;script&gt;alert(1)&lt;/script&gt;</p>
literal  : <p><script>alert(1)</script></p>
|safe    : <p><script>alert(1)</script></p>

আর পুরো server-এর ভেতর দিয়েও একই ফল এসেছিল। প্রথম lab run-এ template-এ {{ x|default:"<script>alert(1)</script>" }} লেখা ছিল, curl-এর শেষ লাইন:

সত্যিকারের run · curl -s /products/ · শুধু শেষ লাইন, দুই সংস্করণের template-এ

# template-এ literal: {{ x|default:"<script>…" }}
<p><script>alert(1)</script></p>
# একই লেখা view থেকে variable হিসেবে: {{ note }}
<p>&lt;script&gt;alert(1)&lt;/script&gt;</p>

ভাবতে পারেন, template-এ নিজে লেখা লেখা তো developer-এর হাতে, বিপদ কোথায়? বিপদ আসে যখন template-এর লেখা অন্য কোথাও থেকে আসে: অনুবাদ ফাইল, ডেটাবেসে রাখা template, অথবা AI-এর কপি করে দেওয়া কোড। আর |safe সাধারণত বসে “HTML ঠিকমতো দেখাচ্ছে না” সমস্যা তাড়াতাড়ি সারাতে। নিচে শেখানোর মডেলে তিনটি পথ নিজে চালিয়ে দেখুন। এটি Django-র আসল engine নয়, Python-এর html.escape দিয়ে নিয়মটি নকল করা।

# শেখানোর মডেল: Django template-এর autoescape, html.escape দিয়ে
from html import escape
import re

def render(template, context):
    def var(m):
        name, _, filt = m.group(1).strip().partition("|")
        value = context.get(name.strip())
        if filt.startswith('default:"') and not value:
            # template-এ লেখা literal আগে থেকেই "safe" ধরা হয়, escape হয় না
            return filt[len('default:"'):-1]
        if filt == "safe":                    # আপনি নিজে দায় নিলেন
            return str(value)
        return escape(str(value))             # ডিফল্ট: সব variable escape
    return re.sub(r"\{\{(.*?)\}\}", var, template)

note = "<script>alert(1)</script>"
print(render("<p>{{ note }}</p>", {"note": note}))
print(render('<p>{{ x|default:"<script>alert(1)</script>" }}</p>', {}))
print(render("<p>{{ note|safe }}</p>", {"note": note}))
print(render("<p>{{ name }}</p>", {"name": "Tom & Jerry's \"Tea\""}))

নিয়ম তিনটি। Template-এ HTML-যুক্ত literal লিখবেন না; লেখা view থেকে variable হিসেবে পাঠান। |safe শুধু সেই HTML-এ, যা আপনি নিজে তৈরি করেছেন বা sanitize করেছেন। আর Content Security Policy দিয়ে দ্বিতীয় স্তরের পাহারা রাখুন; Django 6.0 থেকে CSP-র জন্য নিজস্ব সুবিধা এসেছে। পুরো তালিকা পর্ব ৫০-এ (অ্যাপের নিরাপত্তা তালিকা), আর তত্ত্ব Cybersecurity কোর্সের XSS ও CSP পর্বে.

৮ · Admin, login, session আর CSRF — বাক্সেই তৈরি

Django-র সবচেয়ে বিখ্যাত ব্যাটারি admin. Model নিবন্ধন করলেই তালিকা, খোঁজা, filter, তৈরি-বদল-মোছার পাতা তৈরি হয়ে যায়। বাজারঘরের মালিক এখান থেকেই পণ্য আর দাম সামলাতে পারেন।

from django.contrib import admin
from .models import Category, Product

@admin.register(Product)
class ProductAdmin(admin.ModelAdmin):
    list_display = ['name', 'category', 'price', 'stock']
    list_filter = ['category']
    search_fields = ['name']

admin.site.register(Category)

Admin-এ ঢুকতে একজন staff ব্যবহারকারী লাগে। python manage.py createsuperuser একটি superuser বানায়, আর পাসওয়ার্ড ডিফল্টে PBKDF2 দিয়ে hash হয়ে জমা হয় (password hash, পর্ব ৪৫-এর মতো)। আমাদের run-এ পাসওয়ার্ড ছিল একটি নকল মান, example-pass-731. এবার curl দিয়ে একটি পুরো login দেখি।

$ curl -s -o /dev/null -w "%{http_code} %{redirect_url}" /admin/
302 http://127.0.0.1:8167/admin/login/?next=/admin/

Set-Cookie: csrftoken=…  (৩২ অক্ষর)
<input type="hidden" name="csrfmiddlewaretoken"
       value="VM6KAZk69CEEqdNsnKEazEB1nRR3…">  (৬৪ অক্ষর)
<input type="hidden" name="next" value="/admin/">

403
<p>CSRF verification failed. Request aborted.</p>
Reason given for failure:
    CSRF token missing.
# server log: Forbidden (CSRF token missing.): /admin/login/

200
<p class="errornote">
    Please enter the correct username and password
    for a staff account. Note that both fields may
    be case-sensitive.

302 http://127.0.0.1:8167/admin/
#HttpOnly_127.0.0.1 … sessionid  …  (৩২ অক্ষর)
127.0.0.1           … csrftoken  …  (login-এ Django বদলায়)

$ curl -b cookies.txt /admin/                     → 200
$ curl -b cookies.txt "/admin/shop/product/?category__id__exact=2"
200   Green Tea 100g, Sylhet Tea 400g

সত্যিকারের run · python manage.py test

Found 3 test(s).
System check identified no issues (0 silenced).
...
----------------------------------------------------------------------
Ran 3 tests in 0.015s

OK

তিনটি test: stock ০ হলে পণ্য লুকানো, login ছাড়া admin-এ 302, আর না-থাকা পণ্যে 404. Django-র test client প্রতিটি test-এর জন্য আলাদা test database বানায় আর শেষে মুছে দেয়।

৯ · API, async, settings, deployment আর কখন Django

API: DRF আর Django Ninja

আমাদের JsonResponse ছোট কাজে যথেষ্ট। কিন্তু pagination, গঠিত validation error, token auth আর API docs লাগলে দুটি পরিচিত library আছে। লেখার সময়ে PyPI-তে দেখা সংস্করণ:

দুটির কোনোটি এই lab-এ চালানো হয়নি, তাই এখানে কোড দেখাচ্ছি না। কোনটি বেছে নেবেন, তা দলের অভ্যাসের ওপর নির্ভর করে: DRF পুরোনো বলে এর উদাহরণ আর নথি বেশি জমেছে, Ninja-র কোড ছোট আর type-নির্ভর। Pydantic-এর ধাঁচ বিস্তারিত দেখবেন পর্ব ৬৯-এ, FastAPI-তে।

Async view আর তার সীমা

Django-তে async def দিয়ে async view লেখা যায়, আর QuerySet-এর প্রায় প্রতিটি SQL চালানো method-এর a-যুক্ত রূপ আছে যেমন aget(), acount() আর async for লুপ। তবে Django-র docs কয়েকটি সীমা স্পষ্ট বলে, লেখার সময়ের 6.1 docs অনুযায়ী:

• WSGI-তে async view চলে, কিন্তু লাভ কম: প্রতিটি request-এর জন্য আলাদা ছোট event loop চলে। অনেক লম্বা সংযোগ (streaming, long polling) সামলাতে ASGI-তে deploy করতে হয়।
• Transaction এখনো async mode-এ চলে না। Transaction-এর কোড একটি সাধারণ function-এ রেখে sync_to_async() দিয়ে ডাকতে হয়।
• Async function-এর ভেতরে সাধারণ ORM call দিলে Django SynchronousOnlyOperation error দেয়।
• Middleware sync হলে প্রতিটি request-এ sync আর async-এর মাঝে বদলের খরচ পড়ে।

ভেতরে ORM-এর async method কতটা “আসল” async, অর্থাৎ thread ছাড়া চলে কিনা, তা version আর database driver ভেদে বদলাচ্ছে। তাই সাধারণ CRUD সাইটে async-এ যাওয়ার আগে মেপে দেখুন। বাইরের অনেক API-কে একসাথে ডাকা বা WebSocket-এর মতো কাজে async-এর লাভ সবচেয়ে স্পষ্ট। Python-এর async নিজে বুঝতে Python কোর্সের asyncio পর্ব দেখুন।

Settings, secret আর DEBUG=False

startproject যে settings.py বানায়, তা development-এর জন্য: DEBUG = True, আর SECRET_KEY ফাইলের ভেতরেই লেখা, django-insecure- দিয়ে শুরু। এই key session আর CSRF token সই করতে লাগে, তাই এটি ফাঁস হওয়া মানে বড় বিপদ। নতুন project-এ check --deploy চালালে:

সত্যিকারের run · python manage.py check --deploy · লম্বা বার্তা ছাঁটা

SystemCheckError: System check identified some issues:

ERRORS:
?: (mail.E001) Your MAILERS setting uses a development-only email backend in the 'default' entry (django.core.mail.backends.console.EmailBackend).

WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. …
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. …
?: (security.W009) Your SECRET_KEY has less than 50 characters, less than 5 unique characters, or it's prefixed with 'django-insecure-' …
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. …
?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. …
?: (security.W018) You should not have DEBUG set to True in deployment.
?: (security.W020) ALLOWED_HOSTS must not be empty in deployment.

System check identified 8 issues (0 silenced).

লক্ষ করুন MAILERS: Django 6.1-এ email backend সাজানোর এই নতুন setting এসেছে, যা release notes অনুযায়ী ভবিষ্যতে পুরোনো EMAIL_BACKEND-এর জায়গা নেবে। পুরোনো tutorial-এ শুধু EMAIL_BACKEND পাবেন। Production-এর জন্য আমরা আলাদা একটি settings ফাইল বানালাম, যা secret পড়ে environment variable থেকে:

import os
from .settings import *  # noqa

DEBUG = False
SECRET_KEY = os.environ['DJANGO_SECRET_KEY']      # না থাকলে চালুই হবে না
ALLOWED_HOSTS = (os.environ['DJANGO_ALLOWED_HOSTS'].split(',')
                 if os.environ.get('DJANGO_ALLOWED_HOSTS') else [])

সত্যিকারের run · --settings=bazarghar.settings_prod · secret-এর মান একটি নকল লম্বা লেখা

# DJANGO_SECRET_KEY ছাড়া
KeyError: 'DJANGO_SECRET_KEY'
# secret আছে, ALLOWED_HOSTS নেই
CommandError: You must set settings.ALLOWED_HOSTS if DEBUG is False.
# দুটিই আছে: না-থাকা পণ্য
<title>Not Found</title> … The requested resource was not found on this server.
404
# অচেনা Host header
$ curl -H "Host: evil.example" /products/
400

DEBUG=True-এ একই 404 পাতায় পুরো URL তালিকা দেখাত (Page not found at /api/products/999/), আর error হলে settings ও stack trace. DEBUG=False-এ শুধু ছোট বার্তা। ALLOWED_HOSTS অচেনা Host header-কে 400 দিয়ে ফিরিয়ে দেয়, যা host header দিয়ে বিষাক্ত লিংক বানানোর চেষ্টা থামায়। Secret সামলানোর পুরো পদ্ধতি দেখবেন পর্ব ৭৮-এ, Environment আর secret বিষয়ের পর্বে।

Deployment: WSGI, ASGI আর server

runserver শুধু development-এর জন্য; Django-র docs নিজেই production-এ এটি ব্যবহার করতে নিষেধ করে। Production-এ project-এর wsgi.py বা asgi.py-কে একটি আলাদা server চালায়। WSGI হলো Python web app আর server-এর মধ্যে সাধারণ sync চুক্তি; Gunicorn (লেখার সময়ে 26.2.0) এর পরিচিত server. ASGI হলো async চুক্তি; Uvicorn (লেখার সময়ে 0.54.0) এর একটি server. সামনে সাধারণত Nginx-এর মতো একটি reverse proxy থাকে, যা HTTPS আর static ফাইল সামলায়।

# উদাহরণ, এই lab-এ চালানো হয়নি (Windows-এ gunicorn চলে না)
$ python manage.py collectstatic --noinput
$ python manage.py migrate
$ gunicorn bazarghar.wsgi:application --workers 3 --bind 127.0.0.1:8000
# অথবা ASGI
$ uvicorn bazarghar.asgi:application --workers 3

Docker, CI/CD আর hosting বেছে নেওয়া মডিউল ১২-এ (পর্ব ৮০–৮২) আসবে। আর পর্ব ৮৫-তে Django, Laravel আর Next.js-কে পাশাপাশি রেখে stack বাছাইয়ের ছক বানাবেন।

কখন Django বেছে নেবেন

চাকরির বাজার নিয়ে একটি সতর্ক কথা: Django-র চাহিদা দেশ, শহর আর বছরভেদে বদলায়, তাই কোনো সংখ্যা আমরা দিচ্ছি না। নিজের এলাকার চাকরির বিজ্ঞাপন দেখে বিচার করুন। নীতিগত দিকটি স্থির: একটি framework ভালো করে শিখলে, তার ধারণা (routing, ORM, migration, middleware) অন্যটিতে সহজে নেওয়া যায়।

১০ · AI-এর যুগে: Django কোড যাচাই

Django প্রায় কুড়ি বছরের পুরোনো, তাই ইন্টারনেটে পুরোনো কোড অনেক। AI প্রায়ই সেই পুরোনো ধাঁচ মিশিয়ে দেয়। কোড চলে, কিন্তু আপনার version-এ ভুল বা অনিরাপদ।

AI-এর Django কোড হাতে পেলে

• নিজের version-এর docs-এ প্রতিটি function আর setting খুঁজে পেয়েছি
• sqlmigrate দিয়ে নতুন migration-এর SQL পড়েছি, আর diff লাইন ধরে দেখেছি
• Query সংখ্যা আগে আর পরে মেপেছি, একটি test-এ ধরে রেখেছি
• কোনো view-তে login বা মালিকানা যাচাই বাদ পড়েনি; csrf_exempt আর |safe নেই
• check --deploy পরিষ্কার; secret কোডে বা prompt-এ যায়নি, আর ফাঁকা except দিয়ে error লুকানো হয়নি