Django 6.0 w 2026 roku: Klucze Kompozytowe, Zadania w Tle i Pytania Rekrutacyjne

Django 6.0, wydane w grudniu 2025 roku, wprowadza do najpopularniejszego frameworka webowego Python trzy dlugo oczekiwane funkcjonalnosci: wbudowany system zadan w tle, template partials umozliwiajace definiowanie fragmentow szablonow wielokrotnego uzytku oraz natywne wsparcie dla Content Security Policy. W polaczeniu z kompozytowymi kluczami glownymi wprowadzonymi w Django 5.2, ekosystem Django w 2026 roku oferuje znaczaco rozbudowany zestaw narzedzi do budowania aplikacji produkcyjnych — przy mniejszej zaleznosci od pakietow zewnetrznych niz kiedykolwiek wczesniej.

Kompozytowe klucze glowne z CompositePrimaryKey

Relacyjne bazy danych od dziesiecioleci wykorzystuja kompozytowe klucze glowne do jednoznacznej identyfikacji rekordow na podstawie kombinacji dwoch lub wiecej kolumn. Do momentu wydania Django 5.2 modelowanie takich relacji wymagalo obejsc w postaci unique_together lub pakietow zewnetrznych. Pole CompositePrimaryKey rozwiazuje ten problem bezposrednio na poziomie ORM, eliminujac potrzebe sztucznych kluczy auto-inkrementowanych w tabelach posredniczacych.

Najczestszym przypadkiem uzycia jest tabela lacznikowa, w ktorej kombinacja dwoch kluczy obcych stanowi unikalna tozsamosc rekordu. Ponizszy przyklad modeluje system magazynowy, gdzie kazdy produkt w kazdym magazynie posiada przypisana ilosc:

# models.py
from django.db import models

class Product(models.Model):
    name = models.CharField(max_length=100)
    sku = models.CharField(max_length=20, unique=True)

class Warehouse(models.Model):
    code = models.CharField(max_length=10, primary_key=True)
    location = models.CharField(max_length=200)

class Inventory(models.Model):
    pk = models.CompositePrimaryKey("product_id", "warehouse_id")
    product = models.ForeignKey(Product, on_delete=models.CASCADE)
    warehouse = models.ForeignKey(Warehouse, on_delete=models.CASCADE)
    quantity = models.PositiveIntegerField(default=0)
    last_restocked = models.DateTimeField(auto_now=True)

Pole pk przyjmuje nazwy kolumn bazodanowych (a nie nazwy pol modelu Django). Framework generuje ograniczenie PRIMARY KEY (product_id, warehouse_id) na poziomie bazy danych, gwarantujac unikatowowsc bez koniecznosci dodawania pola id z auto-inkrementacja.

Zapytania do modeli z kluczami kompozytowymi

Interakcja z ORM zachowuje standardowy interfejs znany programistom Django. Klucz kompozytowy jest reprezentowany jako krotka (tuple) Python, co pozwala na filtrowanie, tworzenie i przypisywanie rekordow w sposob intuicyjny:

# views.py
from .models import Inventory, Product, Warehouse

# Create records
laptop = Product.objects.create(name="Laptop Pro", sku="LP-001")
warehouse_a = Warehouse.objects.create(code="WH-A", location="Berlin")

item = Inventory.objects.create(
    product=laptop,
    warehouse=warehouse_a,
    quantity=50
)

# Access the composite pk as a tuple
print(item.pk)  # (1, "WH-A")

# Filter by composite pk
result = Inventory.objects.filter(pk=(1, "WH-A")).first()

# Assign a composite pk directly
new_item = Inventory(pk=(2, "WH-B"))
print(new_item.product_id)  # 2
print(new_item.warehouse_id)  # "WH-B"

Ta funkcjonalnosc okazuje sie szczegolnie wartosciowa w projektach pracujacych z istniejacymi schematami baz danych lub migrujacych z innych ORM, ktore juz wczesniej obslugiwaly klucze kompozytowe. Panel administracyjny Django, serializery Django REST Framework oraz system migracji automatycznie rozpoznaja modele korzystajace z CompositePrimaryKey.

Wbudowany system zadan w tle w Django 6.0

Django 6.0 integruje system zadan w tle bezposrednio w ramach frameworka. Modul django.tasks udostepnia dekorator @task oraz metode .enqueue(), ktore pozwalaja na odroczenie wykonania funkcji bez konfigurowania zewnetrznego brokera wiadomosci czy oddzielnych procesow workerow.

System ten jest ukierunkowany na typowe operacje, ktore nie powinny blokowac cyklu zadanie-odpowiedz HTTP: wysylanie wiadomosci e-mail, generowanie raportow, przetwarzanie plikow oraz wywolania zewnetrznych interfejsow API. Definicja zadan odbywa sie zgodnie z konwencja Django — w module tasks.py w ramach kazdej aplikacji:

# tasks.py
from django.tasks import task
from django.core.mail import send_mail

@task
def send_welcome_email(user_email, username):
    """Send a welcome email after user registration."""
    send_mail(
        subject="Welcome to the platform",
        message=f"Hello {username}, your account is ready.",
        from_email=None,  # uses DEFAULT_FROM_EMAIL
        recipient_list=[user_email],
    )
    return f"Email sent to {user_email}"

@task
def generate_report(report_id, format="pdf"):
    """Generate an export report asynchronously."""
    from .services import ReportService
    report = ReportService.generate(report_id, format=format)
    return report.file_path

Wysylanie zadan z poziomu widoku odbywa sie za pomoca metody .enqueue(), ktora serializuje argumenty i przekazuje je do skonfigurowanego backendu w celu asynchronicznego przetworzenia:

# views.py
from .tasks import send_welcome_email, generate_report

def register_user(request):
    # ... user creation logic ...
    # Enqueue the task for background execution
    send_welcome_email.enqueue(
        user_email=user.email,
        username=user.username
    )
    return redirect("dashboard")

def export_view(request, report_id):
    generate_report.enqueue(report_id=report_id, format="csv")
    return JsonResponse({"status": "processing"})

Django 6.0 dostarcza domyslny backend bazodanowy oraz backend Redis przeznaczony do scenariuszy o wiekszym wolumenie zadan. Konfiguracja w pliku settings.py umozliwia wybor backendu i dostosowanie parametrow takich jak liczba workerow oraz interwal odpytywania.

Nalezy wyraznie okreslic zakres zastosowania tego systemu. Natywne zadania Django 6.0 efektywnie pokrywaja proste i umiarkowanie zlozone przypadki uzycia. W scenariuszach wymagajacych zaawansowanego routingu kolejek, zlozonych przeplywow pracy (chains, chords, groups), konfigurowalnych polityk ponownych prob z wykladniczym cofaniem lub przetwarzania rozproszonego na wielu maszynach, Celery pozostaje odpowiednim narzedziem.

Template Partials — fragmenty szablonow wielokrotnego uzytku

Silnik szablonow Django zyskuje funkcjonalnosc, ktora programisci frontendowi uznaja za oczywista: mozliwosc definiowania fragmentow wielokrotnego uzytku w ramach jednego pliku i selektywnego odwolywania sie do nich. Znaczniki {% partialdef %} i {% partial %} pozwalaja na grupowanie kilku komponentow wizualnych w jednym szablonie i korzystanie wylacznie z potrzebnego fragmentu.

Ponizszy przyklad definiuje dwie reprezentacje produktu — karte do widoku katalogu i wiersz tabeli do inwentaryzacji — w tym samym pliku szablonu:

<!-- templates/components/cards.html -->
{% partialdef product_card %}
<div class="card">
    <h3>{{ product.name }}</h3>
    <p class="price">{{ product.price|floatformat:2 }} EUR</p>
    <span class="stock {% if product.in_stock %}available{% else %}sold-out{% endif %}">
        {% if product.in_stock %}In Stock{% else %}Sold Out{% endif %}
    </span>
</div>
{% endpartialdef %}

{% partialdef product_row %}
<tr>
    <td>{{ product.name }}</td>
    <td>{{ product.price|floatformat:2 }} EUR</td>
    <td>{{ product.quantity }}</td>
</tr>
{% endpartialdef %}

Selektywne dolaczanie konkretnego fragmentu odbywa sie za pomoca skladni #nazwa w znaczniku {% include %}:

<!-- templates/shop/catalog.html -->
{% extends "base.html" %}

{% block content %}
<div class="product-grid">
    {% for product in products %}
        {% include "components/cards.html#product_card" %}
    {% endfor %}
</div>
{% endblock %}

Glowna zaleta template partials jest ograniczenie proliferacji plikow. Przed ich wprowadzeniem kazda wizualna wariant komponentu wymagal osobnego pliku. Obecnie spokrewnione warianty wspolistnieja w jednym pliku, co ulatwia nawigacje w kodzie i upraszcza jego utrzymanie. Funkcjonalnosc ta naturalnie integruje sie z HTMX i innymi wzorcami czuesciowej wymiany HTML, gdzie serwer musi zwrocic konkretny fragment strony bez renderowania calego szablonu.

Natywny middleware Content Security Policy

Ochrona przed atakami cross-site scripting (XSS) i wstrzykiwaniem tresci wymaga poprawnie skonfigurowanych naglowkow Content Security Policy. Django 6.0 integruje dedykowany middleware oraz modul django.utils.csp, ktore eliminuja koniecznosc korzystania z pakietow zewnetrznych takich jak django-csp.

Konfiguracja definiowana jest w pliku settings.py za pomoca slownika, ktory mapuje dyrektywy CSP na dozwolone wartosci:

# settings.py
from django.utils.csp import CSP

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.middleware.security.ContentSecurityPolicyMiddleware",
    # ... other middleware
]

SECURE_CSP = {
    "default-src": [CSP.SELF],
    "script-src": [CSP.SELF, CSP.NONCE],
    "style-src": [CSP.SELF, "https://fonts.googleapis.com"],
    "img-src": [CSP.SELF, "https:", "data:"],
    "font-src": [CSP.SELF, "https://fonts.gstatic.com"],
    "connect-src": [CSP.SELF],
}

# Report-only mode for testing (does not block, only reports violations)
SECURE_CSP_REPORT_ONLY = {
    "default-src": [CSP.SELF],
    "report-uri": ["/csp-report/"],
}

Stala CSP.NONCE automatycznie generuje unikalny nonce dla kazdego zadania i wstrzykuje go do znacznikow <script> w szablonie. Pozwala to na wykonanie legalnych skryptow inline, jednoczesnie blokujac wszelkie skrypty wstrzykniete przez napastnika. Tryb SECURE_CSP_REPORT_ONLY jest szczegolnie przydatny w fazie wdrazania — naruszenia sa rejestrowane bez blokowania zasobow, co umozliwia stopniowe dopracowywanie polityk przed aktywacja trybu blokujacego.

Natywna integracja gwarantuje pelna kompatybilnosc z silnikiem szablonow Django, w tym automatyczne generowanie atrybutow nonce w blokach {% static %} oraz w skryptach inline panelu administracyjnego.

Pozostale istotne zmiany w Django 6.0

Oprocz kluczowych funkcjonalnosci, Django 6.0 wprowadza szereg usprawnien wplywajacych na codzienna prace programistow.

BigAutoField jako domyslne pole klucza glownego: ustawienie DEFAULT_AUTO_FIELD wskazuje teraz na BigAutoField w nowych projektach, usuwajac ograniczenie do 2,1 miliarda rekordow narzucane przez AutoField. Istniejace projekty, ktore nie skonfigurowaly tej wartosci jawnie, otrzymaja ostrzezenie podczas migracji.

Paginacja asynchroniczna: paginowane QuerySety obsluguja metody asynchroniczne takie jak await page.ahas_next() i await page.ahas_previous(). Widoki asynchroniczne moga paginowac wyniki bez blokowania petli zdarzen, co poprawia przepustowosc aplikacji ASGI.

Automatyczne importy w powloce: polecenie python manage.py shell automatycznie importuje wszystkie modele projektu oraz najczesciej uzywane moduly (django.db.models, django.utils.timezone, datetime). Usprawnienie to eliminuje powtarzalne wpisywanie importow przy kazdym otwarciu sesji interaktywnej.

Zmodernizowane API wiadomosci e-mail: modul django.core.mail zyskuje natywna obsluge zalacznikow inline, niestandardowych naglowkow oraz plynny interfejs upraszczajacy tworzenie zlozonych wiadomosci bez bezposredniej manipulacji obiektami MIME.

Pytania rekrutacyjne dotyczace Django w 2026 roku

Rozmowy kwalifikacyjne na stanowiska backendowe Python w 2026 roku coraz czesciej obejmuja pytania dotyczace funkcjonalnosci Django 6.0. Ponizsze pytania pokrywaja tematy najczesciej pojawiajace sie podczas procesow rekrutacyjnych Django.

Pytanie: Czym rozni sie unique_together od CompositePrimaryKey?

unique_together tworzy ograniczenie unikatowosci na zestawie kolumn, lecz model zachowuje pole id z auto-inkrementacja jako klucz glowny. CompositePrimaryKey usuwa pole id i ustanawia kombinacje kolumn jako rzeczywisty klucz glowny na poziomie bazy danych. Pierwsze stanowi dodatkowe ograniczenie; drugie redefiniuje sama tozsamosc rekordu.

Pytanie: Kiedy stosowac natywne zadania Django 6.0 zamiast Celery?

Natywny system zadan sprawdza sie w prostych operacjach niewymagajacych routingu kolejek, zaawansowanych mechanizmow ponownych prob ani zlozonych przeplywow typu canvas (chains, groups, chords). Celery jest niezbedne, gdy aplikacja wymaga przetwarzania rozproszonego na wielu maszynach, zaawansowanego planowania periodycznego (Celery Beat) lub monitoringu w czasie rzeczywistym za pomoca narzedzi takich jak Flower.

Pytanie: W jaki sposob ORM udostepnia kompozytowy klucz glowny?

Wlasciwosc pk instancji modelu korzystajacej z CompositePrimaryKey zwraca krotke (tuple) Python zawierajaca wartosci kolumn wchodzacych w sklad klucza. Filtrowanie odbywa sie za pomoca Model.objects.filter(pk=(wartosc1, wartosc2)), a przypisanie za pomoca instancja = Model(pk=(wartosc1, wartosc2)). ORM automatycznie rozpakowuje krotke do odpowiadajacych pol modelu.

Pytanie: Jaka korzysc daja template partials w porownaniu z wieloma oddzielnymi plikami include?

Template partials pozwalaja definiowac wiele fragmentow wielokrotnego uzytku w jednym pliku, ograniczajac proliferacje drobnych plikow i ulatwiajac nawigacje w kodzie. Skladnia {% include "plik.html#nazwa" %} odwoluje sie selektywnie do konkretnego fragmentu, co dodatkowo integruje sie z wzorcami czesciowej wymiany HTML, takimi jak HTMX.

Pytanie: Jak dziala tryb report-only middleware CSP i kiedy nalezy go stosowac?

Tryb SECURE_CSP_REPORT_ONLY rejestruje naruszenia polityki Content Security Policy bez blokowania zasobow. Nalezy go stosowac w fazie wdrazania, aby zidentyfikowac zasoby naruszajace politike i stopniowo dopracowac dyrektywy CSP. Po potwierdzeniu, ze wszystkie zasoby spelniaja politike, nastepuje przelaczenie na tryb blokujacy (SECURE_CSP), ktory aktywnie zapobiega ladowaniu niedozwolonych zasobow.

Pytanie: Dlaczego Django 6.0 zmienilo domyslne pole klucza glownego na BigAutoField?

AutoField (32-bitowy integer) ogranicza tabele do okolo 2,1 miliarda rekordow — limit, ktory w produkcyjnych aplikacjach o duzym wolumenie moze zostac osiagniety. BigAutoField (64-bitowy integer) podnosi ten limit do ponad 9 trylionow rekordow, eliminujac ryzyko wyczerpania kluczy glownych bez koniecznosci recznej konfiguracji w nowych projektach.

Podsumowanie

• Kompozytowe klucze glowne eliminuja potrzebe sztucznych pol id w tabelach posredniczacych i relacyjnych, dostosowujac ORM Django do standardowego modelu relacyjnego baz danych
• Natywne zadania w tle redukuja zlozonosc operacyjna dla prostych operacji asynchronicznych, eliminujac zaleznosc od zewnetrznego brokera i oddzielnych procesow workerow
• Template partials organizuja fragmenty szablonow wielokrotnego uzytku w ramach jednego pliku, ograniczajac proliferacje szablonow i ulatwiajac integracje z wzorcami czesciowej wymiany HTML, takimi jak HTMX
• Natywny middleware CSP zapewnia ochrone przed atakami XSS z automatycznym generowaniem nonce oraz trybem report-only umozliwiajacym stopniowe wdrazanie polityk bezpieczenstwa
• BigAutoField jako domyslny klucz zapobiega wyczerpaniu kluczy glownych w tabelach o duzym wolumenie bez dodatkowej konfiguracji
• Paginacja asynchroniczna oraz automatyczne importy w powloce poprawiaja codzienna produktywnosc programistow zarowno w kodzie produkcyjnym, jak i podczas sesji debugowania
• Django 6.0 wymaga Pythona 3.12 lub nowszego i zachowuje kompatybilnosc z glownymi obslugiwanymi bazami danych (PostgreSQL, MySQL, SQLite, Oracle)