# Django 6.0 w 2026 roku: Klucze Kompozytowe, Zadania w Tle i Pytania Rekrutacyjne
> Przewodnik po Django 6.0 w 2026: kompozytowe klucze glowne, wbudowany system zadan w tle, template partials, middleware CSP oraz pytania rekrutacyjne z przykladami kodu.
- Published: 2026-06-09
- Updated: 2026-06-09
- Author: SharpSkill
- Tags: django, python, composite-primary-keys, background-tasks, csp
- Reading time: 10 min
---
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.
> **Harmonogram wersji Django w 2026 roku**
>
> Django 5.2 LTS (kwiecien 2025) wprowadzilo kompozytowe klucze glowne. Django 6.0 (grudzien 2025) dodalo system zadan w tle, template partials i middleware CSP. Django 6.1 jest obecnie w fazie aktywnego rozwoju i przewiduje wprowadzenie trybów pobierania pol (field fetch modes).
## 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:
```python
# 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:
```python
# 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:
```python
# 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:
```python
# 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](/pl/blog/django/django-celery-async-tasks-interview-2026) 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:
```html
{% partialdef product_card %}
{{ product.name }}
{{ product.price|floatformat:2 }} EUR
{% if product.in_stock %}In Stock{% else %}Sold Out{% endif %}
{% endpartialdef %}
{% partialdef product_row %}
| {{ product.name }} |
{{ product.price|floatformat:2 }} EUR |
{{ product.quantity }} |
{% endpartialdef %}
```
Selektywne dolaczanie konkretnego fragmentu odbywa sie za pomoca skladni `#nazwa` w znaczniku `{% include %}`:
```html
{% extends "base.html" %}
{% block content %}
{% for product in products %}
{% include "components/cards.html#product_card" %}
{% endfor %}
{% 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:
```python
# 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 `