A apărut următoarea problemă: pentru unele aplicații a trebuit să eliminați etichetele = TaggableManager (blank = True) (și, prin urmare, dependența de django-taggit). Ca de obicei, am șterge acest domeniu și apelează la makemigration, care și-a făcut treaba așa cum ar trebui. Dar atunci când sunați la migrarea pentru un alt proiect cu același set de migrații, apare o eroare ca aplicația taggit nu a fost găsită pentru a efectua migrații. Desigur, este de asemenea logic ca migrațiile să necesite această aplicație.
Acum înțeleg că a fost ușor să remediați migrările în care a fost creat câmpul taggit și unde a fost șters, deci dacă nu ați făcut acest lucru și ați modificat structura de date a tabelului, acțiunile descrise mai jos vă pot ajuta.
Transferul datelor dintr-o tabelă cu structuri diferite
Să presupunem că avem o aplicație de proiecte și un tabel projects_project cu câmpuri:
Vrem următoarea structură:
Astfel, vedem următoarele modificări:
- title_in_link a fost redenumit pentru a sugera.
- Câmpul is_boder a fost adăugat și este obligatoriu pentru umplere.
- border_width, care poate fi gol.
- Campul de etichete a fost eliminat
Și acum "manual" corectați structura mesei:
- Redenumiți tabelul: projects_project -> projects_project_old.
- Ștergem toate migrările aplicațiilor și, de asemenea, ștergem înregistrările de migrare corespunzătoare din tabela django_migrations din baza de date.
Și ștergeți toate liniile găsite.
- Apelăm makemigration pentru a forma 0001_initial.py (înțelegem că trebuie să restaurăm tabelul cu comenzi sql).
- Suntem migrați și vedem că baza de date projects_project a fost creată în baza de date cu structura de date corectă.
- Vom scrie codul de transfer de date sql de la projects_project_old la projects_project:
Analizați un exemplu: după cum puteți vedea, există o corespondență a câmpurilor pentru umplere. Nu am găsit un exemplu calitativ pe Internet, de aceea sa născut acest post, pentru a umple acest lucru :)
Rețineți că BORDER_WIDTH nu putem umple, deoarece poate fi gol, dar is_border trebuie sa umplem, dar din moment ce nu avem informatii despre acest domeniu, cel mai simplu - este de a umple o valoare de FALSE pentru fiecare înregistrare. Ca o opțiune, puteți apoi să scrie o migrare Django pentru a popula câmpuri TRUE sau FALSE în funcție de disponibilitatea de orice valoare în border_color domeniu, dar asta e altă poveste.
De asemenea, rețineți că câmpul de comandă se potrivește cu cuvântul de serviciu sql, deci trebuie să faceți dublu-citat acest câmp.
- Ștergeți tabelul projects_project_old.
Asta e tot. Încă o dată, acest exemplu este pentru cei care au rupt accidental structura de date a mesei sau migrația sa stricat sau, ca mine, am eliminat dependențele din aplicație. Aceasta este o metodă lungă "sql-manual" pentru a repara structura, deci înainte de a șterge migrațiile, încercați să le reparați pur și simplu :)
Transferul datelor din tabelele conectate
Să presupunem că există o masă: galerie și imagine. Tabela de imagini conține cheia externă de pe masa de galerie.
Acest caz este un pic mai complicat: atunci când încercați să efectuați etapa 4 descrisă mai sus, django este probabil să jure după cum urmează:
Pentru a rezolva problema, trebuie să redenumiți indexul:
Acest lucru se poate face prin interfața grafică pgadmin:
Indicele de care avem nevoie este evidențiat în verde. Faceți clic dreapta pe index făcând clic pe meniul contextual și selectați proprietățile:
Aici trebuie să redenumiți indexul, de exemplu, adăugând "_old".
Acum încercăm din nou să efectuăm pasul 4 și apoi să urmăm restul pașilor descriși mai sus.
0 din 5 (total 0 evaluări)
Articole similare
Trimiteți-le prietenilor: