Migracje w Django – od podstaw do eksperta część 2

Witajcie w drugiej części postu dotyczącego migracji w Django. Jeśli jeszcze nie czytaliście części pierwszej, znajdziecie ją tutaj -> Migracje w Django - część 1

Dziś skupimy się na takich aspektach:

5. Migracje danych: Jak dodać pole z unikalną zawartością, gdy już mamy dane w bazie?
6. Jak rozwiązać konflikty w migracjach?
7. Jak, dzięki automatyzacji, nie zapomnieć dodać migracji do projektu
8. Najpopularniejsze błędy migracji z Django i jak je rozwiązać
9. Obiecany BONUS: Czym jest --fake w migracjach Django?

Zapraszam!

Migracje danych: Jak dodać pole z unikalną zawartością, gdy już mamy dane w bazie?

Gdy nasza baza danych jest już wypełniona danymi, dodanie pola z unikalną zawartością wymaga specjalnego podejścia. Nie chcemy przecież naruszyć integralności danych lub spowodować błędów. Dodatkowo, wprowadzenie tego pola na produkcje musi być szczególnie bezbolesne.

Wyobraźmy sobie, że mamy model Product w naszym sklepie internetowym, i chcemy dodać do niego pole slug, które będzie używane w przyjaznych dla SEO adresach URL. Pole to musi być unikalne dla każdego produktu, ale jak to zrobić, gdy mamy już setki lub tysiące produktów w bazie?

Krok po kroku: Dodajemy pole slug do modelu Product

1. Modyfikacja modelu

Najpierw dodajmy pole slug do naszego modelu:

from django.db import models
from django.utils.text import slugify

class Product(models.Model):
    name = models.CharField(max_length=100)
    slug = models.SlugField(unique=True, null=True)  # Zauważ null=True
    # inne pola...

    def save(self, *args, **kwargs):
        if not self.slug:
            self.slug = slugify(self.name)
        super().save(*args, **kwargs)

Zwróćcie uwagę na null=True. To kluczowe, aby nasza pierwsza migracja przeszła bez problemów. Dodaje pole z pustą zawartością.

2. Tworzenie i aplikowanie pierwszej migracji

python manage.py makemigrations
python manage.py migrate

Ta migracja doda pole slug i pozwoli na wartości null.

3. Migracja danych

Teraz musimy wypełnić pole slug dla istniejących produktów. Utworzymy nową migrację danych:

python manage.py makemigrations --empty myapp --name populate_product_slugs

Edytujemy utworzony plik migracji:

from django.db import migrations
from django.utils.text import slugify

def populate_slugs(apps, schema_editor):
    Product = apps.get_model('myapp', 'Product')
    for product in Product.objects.all():
        counter = 1
        slug = slugify(product.name)
        while Product.objects.filter(slug=slug).exists():
            slug = f"{slugify(product.name)}-{counter}"
            counter += 1
        product.slug = slug
        product.save()

class Migration(migrations.Migration):

    dependencies = [
        ('myapp', '0001_previous_migration'),
    ]

    operations = [
        migrations.RunPython(populate_slugs),
    ]

Ta migracja generuje unikalne wartości pola slug dla wszystkich istniejących produktów. W przypadku konfliktu, po prostu doda kolejny numer do produktu, czyli możemy mieć np. "buty-sportowe", "buty-sportowe-1" i "buty-sportowe-2".

4. Aplikowanie migracji danych

python manage.py migrate

5. Usunięcie null=True

Teraz, gdy wszystkie produkty mają slugi, możemy usunąć null=True:

class Product(models.Model):
    name = models.CharField(max_length=100)
    slug = models.SlugField(unique=True)  # Usunięto null=True
    # inne pola...

6. Finalna migracja

python manage.py makemigrations
python manage.py migrate

Potencjalne problemy i rozwiązania

1. Długie migracje: Dla dużych baz danych, proces może być czasochłonny. Można podzielić migracje na mniejsze partie.

2. Konflikty slugów: Nasza metoda dodaje licznik do slugów w przypadku konfliktów. To już zależy od wymagań biznesowych.

3. Unikalne ograniczenia: Dodawanie ograniczenia unique=True na produkcji to droga do katastrofy. Zawsze sprawdzajcie, czy wszystkie wartości są unikalne przed dodaniem tego warunku do istniejących kolumn.

4. Transakcje: Dla bardzo dużych baz danych, może być konieczne ręczne zarządzanie transakcjami w migracji danych.

Dodanie unikalnego pola do istniejącego modelu z danymi w bazie to złożony proces, który wymaga starannego planowania i wykonania. Kluczowe kroki obejmują:

1. Dodanie pola z null=True: Pozwala to na przeprowadzenie pierwszej migracji bez problemów.
2. Migracja danych: Wypełnienie nowego pola unikalnymi wartościami dla istniejących rekordów.
3. Usunięcie null=True: Po wypełnieniu danych możemy usunąć możliwość przechowywania wartości null.
4. Finalna migracja: Aplikowanie zmian do bazy danych.

Pamiętajcie, że każda baza danych i każdy projekt są inne, więc zawsze testujcie swoje migracje na kopii produkcyjnej bazy danych przed wdrożeniem. Dzięki temu unikniecie niespodzianek i zapewnicie płynne działanie aplikacji.

Jak rozwiązywać konflikty w migracjach?

Konflikty w migracjach Django to częsty problem, szczególnie w projektach z wieloma programistami lub rozgałęzieniami kodu. Oto jak możemy sobie z nimi radzić:

1. Zrozumienie problemu

Konflikty w migracjach najczęściej występują, gdy:

• Dwie gałęzie kodu wprowadzają zmiany do tego samego modelu.
• Migracje są tworzone niezależnie w różnych gałęziach.

Czyli na przykład, gdy dwóch programistów modyfikuje ten sam plik models.py w tym samym czasie.

2. Identyfikacja konfliktu

Django informuje o konflikcie podczas próby zastosowania migracji:

django.db.migrations.exceptions.InconsistentMigrationHistory: Migration myapp.0003_auto_20230101_1200 is applied before its dependency myapp.0002_auto_20230101_1100 on database 'default'.

3. Strategie rozwiązywania konfliktów

a) Użycie makemigrations --merge

Django oferuje wbudowane narzędzie do rozwiązywania konfliktów migracji:

python manage.py makemigrations --merge

Ta komenda:

1. Analizuje konfliktujące migracje.
2. Próbuje automatycznie połączyć je w jedną spójną migrację.
3. Jeśli automatyczne połączenie jest niemożliwe, prosi o ręczną interwencję.

Przykład użycia:

$ python manage.py makemigrations --merge
Merging myapp
  Branch 0002_auto_20230101_1100
  Branch 0003_auto_20230101_1200
    Merging operations
      Keeping operation AddField on Product
      Keeping operation AlterField on Product
Created new merge migration myapp/migrations/0004_merge_20230101_1300.py

W tym przypadku Django utworzyło nową migrację łączącą konfliktujące zmiany.

b) Ręczne łączenie migracji

Jeśli --merge nie rozwiąże problemu automatycznie:

1. Stwórz nową, pustą migrację:

   python manage.py makemigrations --empty myapp --name merge_migrations

2. Edytuj nową migrację, dodając obie konfliktujące migracje jako zależności:

   dependencies = [
      ('myapp', '0002_auto_20230101_1100'),
      ('myapp', '0003_auto_20230101_1200'),
   ]

   To zaawansowane rozwiązanie, wymaga dodania migracji w odpowiedniej kolejności i przetestowania.

c) Squashing migracji

Squashing migracji to potężne narzędzie w Django, szczególnie przydatne w projektach z długą historią zmian. Oto jak to działa:

1. Wykonanie squashingu:

   python manage.py squashmigrations myapp 0001 0005

   Ta komenda połączy migracje od 0001 do 0005 w aplikacji myapp w jedną nową migrację. Powinno poradzić sobie z konfliktami.
    

2. Co się dzieje podczas squashingu:
   • Django analizuje wszystkie operacje w wybranych migracjach.
   • Tworzy nową migrację, która zawiera skumulowany efekt wszystkich łączonych migracji.
   • Optymalizuje operacje, usuwając zbędne lub anulujące się nawzajem zmiany.
      
3. Rezultat:
   • Powstaje nowy plik migracji, np. 0006_squashed_0001_0005.py.
   • Oryginalne migracje pozostają nietknięte.
      
4. Zastosowanie squashed migration:
   • W nowych instalacjach: Django użyje tylko squashed migration.
   • W istniejących bazach: Django sprawdzi, które z oryginalnych migracji zostały już zastosowane i odpowiednio dostosuje proces.
      
5. Zalety:
   • Przyspiesza proces migracji w nowych instalacjach.
   • Upraszcza historię migracji, ułatwiając zarządzanie projektem.
      
6. Uwagi:
   • Po squashingu i przetestowaniu, możesz usunąć oryginalne migracje, ale tylko jeśli jesteś pewien, że nie są już potrzebne - czyli wszyscy członkowie zespołu mają aktualną wersję bazy danych. Jeśli ktoś pojechał na długi urlop (w końcu mamy lipiec) to lepiej poczekać z usuwaniem plików, aż wróci.
   • Zawsze testuj squashed migrations przed wdrożeniem na produkcję.

Squashing jest szczególnie przydatny w dużych projektach z setkami migracji, gdzie może znacząco przyspieszyć proces konfiguracji nowych środowisk i ułatwić zarządzanie historią zmian w bazie danych. Również szybkość wykonywania testów wzrośnie.

4. Lepiej zapobiegać niż leczyć

W celu uniknięcia konfliktów migracji:

• Regularnie synchronizuj kod między gałęziami.
• Unikaj długotrwałych gałęzi z dużymi zmianami w modelach.

5. Testowanie rozwiązań

Po rozwiązaniu konfliktu zawsze testuj migracje:

python manage.py migrate --dry-run

To polecenie sprawdzi, czy w migracjach nie ma błędów i ewentualnie je wskaże.

Rozwiązywanie konfliktów w migracjach wymaga ostrożności i zrozumienia historii zmian w projekcie. Narzędzie makemigrations --merge jest ogromnym sprzymierzeńcem, jednak nie zawsze rozwiąże wszystkie problemy automatycznie. Kluczowe jest testowanie rozwiązań przed zastosowaniem ich w środowisku produkcyjnym. Każdy przypadek może być inny i czasami może wymagać indywidualnego podejścia.

Jak, dzięki automatyzacji, nie zapomnieć dodać migracji do projektu

Zapominanie o dodaniu migracji do repozytorium projektu to częsty problem, który może prowadzić do niespójności w bazie danych i frustracji zespołu. Oto kilka strategii automatyzacji, które pomogą Ci zawsze pamiętać o migracjach:

1. CI/CD pipeline

Wykorzystaj narzędzia CI/CD (np. GitLab CI, GitHub Actions) do automatycznego sprawdzania migracji.

Przykład dla GitHub Actions:

Utwórz plik .github/workflows/check-migrations.yml:

name: Check Migrations

on: [push, pull_request]

jobs:
  check-migrations:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: '3.x'
    - name: Install dependencies
      run: |
        pip install django
    - name: Check for unmigrated changes
      run: |
        python manage.py makemigrations --check --dry-run

Ta akcja sprawdzi, czy wszystkie zmiany w modelach mają odpowiadające im migracje. Zadziała na każdą komendę git push oraz sprawdzi każdego pull requesta. Tak, możesz ten plik dołączyć do swojego projektu, zadziała od razu. GitHub ma dużą pulę bezpłatnych uruchomień akcji, więc nie będzie żadnych kosztów.

2. Skrypty pre-push

Możesz utworzyć skrypt pre-push, który sprawdzi migracje przed wysłaniem zmian do zdalnego repozytorium.

Utwórz plik .git/hooks/pre-push:

#!/bin/bash

# Uruchom makemigrations w trybie --check
python manage.py makemigrations --check

if [ $? -ne 0 ]; then
    echo "BŁĄD: Wykryto niezmigrowane zmiany w modelach. Utwórz i dodaj migracje przed pushem."
    exit 1
fi

Wada: to, że plik z migracją jest stworzony u Ciebie na komputerze, nie znaczy że jest w repozytorium. Czyli to sprawdzenie przejdzie, ale akcja z pkt.1 i tak pokaże że migracji nie ma.

3. Aliasy Git

Utwórz alias, który zawsze sprawdza migracje przed commitem:

git config --global alias.commit-with-migrations '!python manage.py makemigrations --check && git commit'

Teraz możesz użyć git commit-with-migrations zamiast git commit. To polecenie ma tą sama wade co wcześniejsze - nie sprawdza czy pliki z migracjami są dodane, do repo, tylko czy w ogóle istnieją.

Automatyzacja sprawdzania migracji znacząco zmniejsza ryzyko pominięcia zmian w bazie danych. Wielokrotnie widziałem sytuacje, gdy developer zwyczajnie zapomniał dodać migracji do commita. Wysłanie takiej zmiany na produkcje to przepis na katastrofę, stąd automatyka jest tak ważna.
Najbardziej z powyższego zestawu polecam metode #1 czyli GitHub Actions. Jest to niezbędne by zapewnić stabilność projektu. Warto jednak uzupełnić ją o #2 lub #3.

Najlepsza automatyzacja to taka, która nie przeszkadza w codziennej pracy, ale skutecznie zapobiega potencjalnym problemom.

Najpopularniejsze błędy migracji w Django i jak je rozwiązać

Migracje w Django, choć potężne, mogą czasem sprawiać problemy. Oto kilka najczęstszych błędów i sposoby ich rozwiązania:

1. Konflikt migracji

Zajrzyj do sekcji "Jak rozwiązywać konflikty w migracjach?"

2. Błąd "table already exists"

Błąd:

django.db.utils.OperationalError: table "myapp_mytable" already exists

Rozwiązanie:

• Sprawdź, czy migracja nie została już częściowo zastosowana.
• Użyj python manage.py migrate --fake-initial, aby oznaczyć początkową migrację jako zastosowaną. fake jest omówione w sekcji bonusowej.

3. Błąd "no such table"

Błąd:

django.db.utils.OperationalError: no such table: myapp_mytable

Rozwiązanie:

• Upewnij się, że wszystkie migracje zostały zastosowane: python manage.py migrate.
• Sprawdź, czy nazwa tabeli w kodzie odpowiada rzeczywistej nazwie w bazie danych.

4. Błąd "column already exists"

Błąd:

django.db.utils.OperationalError: column "new_field" already exists

Rozwiązanie:

• Sprawdź, czy pole nie zostało już dodane ręcznie lub przez inną migrację.
• Użyj python manage.py migrate --fake myapp, aby oznaczyć problematyczną migrację jako zastosowaną.

5. Błąd "cannot add a NOT NULL column with default value NULL"

Błąd:

django.db.utils.OperationalError: cannot add a NOT NULL column with default value NULL

Rozwiązanie:

• Dodaj domyślną wartość do pola w modelu.
• Alternatywnie, wykonaj kroki z sekcji "Jak dodać pole z unikalną zawartością, gdy już mamy dane w bazie?"

Ogólne wskazówki przy rozwiązywaniu problemów z migracjami:

1. Zawsze twórz kopię zapasową bazy danych przed aplikowaniem złożonych migracji.
2. Używaj python manage.py sqlmigrate app_name migration_name, aby zobaczyć SQL generowany przez migrację.
3. W przypadku poważnych problemów rozważ użycie --fake lub --fake-initial z ostrożnością.
4. Pamiętajcie o różnicach między środowiskami (dev, staging, produkcja) - migracja może działać na jednym, a zawodzić na innym.

Pamiętajcie, że rozwiązywanie problemów z migracjami wymaga ostrożności, szczególnie w środowisku produkcyjnym. Zawsze dokładnie analizujcie problem i jego potencjalne rozwiązania przed podjęciem działań.

Bonus: Czym jest --fake w migracjach Django?

Flaga --fake w kontekście migracji Django to narzędzie, które pozwala na manipulację stanem migracji bez faktycznego wykonywania operacji na bazie danych.

Podstawowa koncepcja

Gdy używasz --fake z komendą migrate, Django oznacza migrację jako zastosowaną w swojej wewnętrznej tabeli django_migrations, ale nie wykonuje faktycznych operacji SQL na bazie danych.

Jak to działa?

python manage.py migrate myapp 0003_some_migration --fake

1. Django oznacza migrację 0003_some_migration (i wszystkie poprzedzające, jeśli nie były zastosowane) jako wykonane.
2. Żadne rzeczywiste zmiany nie są wprowadzane do schematu bazy danych.

Kiedy używać --fake?

1. Synchronizacja stanu migracji:
   Gdy schemat bazy danych jest już aktualny, ale Django tego nie wie (np. po ręcznych zmianach w bazie).
    
2. Rozwiązywanie konfliktów:
   Gdy masz konflikt między stanem bazy a migracjami (np. tabela już istnieje, ale Django próbuje ją utworzyć).
    
3. Migracja dużych baz danych:
   Możesz ręcznie wprowadzić zmiany w bazie, a następnie użyć --fake do synchronizacji stanu migracji.
    
4. Przeskakiwanie problematycznych migracji:
   W sytuacjach awaryjnych, gdy konkretna migracja powoduje problemy.

Przykłady użycia

1. Oznaczenie wszystkich migracji jako zastosowane:

   python manage.py migrate --fake myapp

2. Cofnięcie do konkretnej migracji bez modyfikacji bazy:

   python manage.py migrate myapp 0002_previous_migration --fake

Ostrzeżenia

1. Używaj --fake ostrożnie, szczególnie w środowisku produkcyjnym.
2. Upewnij się, że rozumiesz aktualny stan bazy danych przed użyciem tej flagi.
3. Po użyciu --fake, stan bazy może nie odpowiadać stanowi migracji w Django - bądź tego świadomy.

Flaga --fake to wielkie narzędzie do manipulacji stanem migracji w Django. Pozwala na synchronizację stanu migracji z rzeczywistym stanem bazy danych, co jest szczególnie przydatne w sytuacjach, gdy standardowe podejście zawodzi. Jednak ze względu na potencjalne ryzyko, powinna być używana z rozwagą i pełnym zrozumieniem jej działania.

Zakończenie

Migracje w Django są kluczowym elementem zarządzania zmianami w strukturze bazy danych. Dzięki nim możemy automatycznie synchronizować schemat bazy z definicjami modeli w kodzie aplikacji, co ułatwia pracę całemu zespołowi i minimalizuje ryzyko błędów.

Przez cały ten oraz pierwszy post, omówiliśmy:

1. Czym są migracje w Django i jaka jest ich historia.
2. Jak działają migracje na przykładzie modelu produktu w sklepie internetowym.
3. Jak cofać migracje i zarządzać zmianami wstecz.
4. Jak wykonywać migracje danych.
5. Jak dodać pole z unikalną zawartością do istniejącego modelu z danymi.
6. Jak rozwiązywać konflikty w migracjach.
7. Jak dzięki automatyzacji, nie zapomnieć o dodaniu migracji do projektu.
8. Najpopularniejsze błędy migracji i sposoby ich rozwiązania.
9. Czym jest --fake w migracjach Django i jak go używać.

Migracje są narzędziem, które nie tylko usprawnia proces tworzenia i rozwijania aplikacji, ale także zwiększa jej bezpieczeństwo i stabilność. Warto poświęcić czas na naukę i zrozumienie mechanizmów migracji, aby móc w pełni wykorzystać ich potencjał. Pamiętajcie również, że automatyzacja procesów związanych z migracjami może znacznie ułatwić codzienną pracę i zapobiec wielu problemom.

Dzięki przemyślanemu podejściu do migracji możemy tworzyć bardziej efektywne, skalowalne i łatwiejsze w utrzymaniu aplikacje. Mam nadzieję, że ten poradnik pomógł Wam lepiej zrozumieć, jak działają migracje w Django i jak z nich skutecznie korzystać. Zachęcam do eksperymentowania i wdrażania opisanych tu technik w swoich projektach.

---

Dołącz do społeczności PyMasters, gdzie możesz wziąć udział w ciekawych projektach i podnosić swoje umiejętności w Pythonie i Django.

Pobierz mój bezpłatny ebook: WARSZTAT JUNIORA Przewodnik po kluczowych kompetencjach i narzędziach dla początkującego programisty Pythona

Dziękuję za uwagę i życzę udanych migracji!

Zapraszam do zadawania pytań przez formularz kontaktowy. Pamiętaj, że jeśli potrzebujesz wsparcia, możesz napisać do mnie - pomogę.

Spodobał Ci się post?
Podziel się nim!

Masz uwagi do posta, chcesz porozmawiać, szukasz pomocy z Pythonem i Django? Napisz do mnie!