Bu nedenle,
veri modellerine,
geçişlere ve veritabanına ilk baktığınızda kafanızın karışması oldukça kolaydır.
Ve bu yüzden bunu biraz daha ayrıntılı olarak incelemek istiyorum.
Yani makemigrations
models.py dosyalarını okur ve sonra
geçiş denir ne oluşturur.
Ve önemli olan bu,
settings.py dosyasındaki uygulamaların listesi tarafından yönlendirilmesidir.
Yani yeni bir şey yapmak ve yeni bir uygulama
yapmak, ve modeller dosyasını düzenlemek ve
bir makemigrations çalıştırmak deneyin ve
gibi bir şey görmüyorsa, sadece ne yaptı?
Peki, settings.py dosyasını düzenledin mi? Çünkü
settings.py dosyanızda yüklü uygulamalar denilen bir şey var.
Şimdi, geçişler veritabanları arasında taşınabilir.
Bu,
geçişin tabloların nasıl görünmesi gerektiğinin mantıksal bir açıklaması olduğu ve bunların bir evrim olduğu anlamına gelir.
Ne demek istedikleri,
bu tablonun ilk sürümü gibidir,
ilk models.py geçişler ilk çalıştırıldığında, 001'dir.
Ve sonra models.py
değiştirirseniz ve bir geçiş yeniden çalıştırırsanız,
001 models.py ve sonra 002 geçiş değişikliklerine bakar
ve sonra 002, hepsini silip baştan başlamak
gibi değildir, “Oh bekle, sadece bir sütun eklediniz.
Ben gidip o sütunu ekleyeceğim.” Ama
gerçek SQL olan bir şekilde yapılmadı.
Bu nedenle,
geçişler kendileri
Python benzerdir ve veritabanları arasında taşınabilirdir, bu da
bilgisayarınızda SQLite'ı
kullanabileceğiniz anlamına gelir ve üretimde MySQL'i kullanabilirsiniz ve
göçler
her ikisi için de aynıdır, çünkü onlar sadece şöyle diyorlar: sütunlar, işte türleri,
işte olmaları gereken şey.”
Şimdi, bunu bir göç komutuyla karşılaştırın.
Geçiş komutu
tüm geçişleri okur
ve hangi veritabanıyla
konuştuğunu bilir ve gerekli tabloları oluşturmak
ve/veya gerekli tabloları geliştirmek için SQL komutlarını çalıştırır.
Görünüyor ve diyor ki: “İşte
ilk göç, işte ikinci göç,
işte üçüncü göç.
Tabloyu
yapacağım, tabloyu değiştireceğim, tabloyu
değiştireceğim, tabloyu değiştireceğim ve
tüm geçişin sonunda,
göç daha sonra
tüm geçişlerden geçer ve ardından
göçlerin toplamını yansıtan bir veritabanı tablosuna sahiptir. en son models.py dosyası.
Yani biraz karmaşık.
Veritabanı taşınabilirliği
ve bunun
taşınabilir parçalarını
taşınabilir olmayan parçalardan ayırmak istediğimiz gerçeğiyle ilgili.
Eğer göçlere bakarsanız
ve burada bir dj4e örneği,
benim küçük numune maddelerim,
orada bir sürü model var.
Ve tüm models.py dosyalarına
bakarsanız,
dj4e örnekleri projesindeki her uygulama için
bir models.py dosyası görürsünüz ve bu bir
Python kodu, sınıf, kitap, vesaire, vesaire.
Bu çok taşınabilir ve
Python kodumuzda, Django kodumuzda,
veritabanı modelini böyle görüyoruz.
Ve
makemigration'ı çalıştırdığınızda, bu göç dosyalarını üretir ve
onlar sadece autos/migrations/001_initial.py gibi, vb.
Ve burada sahip olduklarımdan bazılarını görüyorsunuz,
aslında ikisi var.
Bu yüzden birincisini yaptı
ve sonra model dosyasını değiştirmiş olmalıyım,
ve sonra tekrar makemigrations çalıştırdım ve
bu modelin
model
dosyasının ilk sürümünden ikinci sürüme nasıl değiştiğini kaydetti.
Bunlara bakabilir, ancak
düzenleyemezsiniz, GitHub'a kontrol edebilirsiniz, ancak bunları düzenlemeyin.
Ama bir bak. Çok taşınabilir bir temsilcilerdir.
models.py dosyasına benziyorlar.
Onları değiştirmemeniz gerekiyor. Onları
göç ederek yaratmanız gerekiyor. Ve yine,
bunlar GitHub'a girebilir.
Şimdi, geçiş temel olarak
tüm bu geçiş dosyalarını okur ve
yalnızca bir tane değil, ancak
bir geçiş dosyası dizisi varsa,
hepsini gerektiği gibi sırayla uygular.
Ve eğer
veritabanında birinci ve ikinci geçiş uygulanmışsa
ancak üçüncü geçiş uygulanmamışsa,
bunu bilir ve der ki, “Biliyor musun,
zaten mevcut olan bu veritabanını ayarlayacağım,
ve sonra bir sütun ekleyeceğim veya bir
sütunun genişliğini değiştireceğim veya
models.py dosyanızı düzenleyerek yapılmasını istediğiniz şey ne olursa olsun.”
Böylece geçiş işlemi tamamlandığında,
veritabanınızda bir sürü tablo ile sonuçlanır ve hepsi
uygulamanın adını ve uygulama
içindeki modelin adını temel alır.
Ve burada bir yerde bookone_book,
bookone_instance ve bookone_lang var.
Bunların hepsi orada oturuyor.
Ve bütün masalar bunlar. Daha
önce de şu masalara baktık.
Ama bu,
projedeki tüm uygulamalara yayılmış tüm küçük geçişlerden kaynaklanan ve sonra tüm bunlara
sahip bir veritabanını bir araya getiren geçiş.
Ve sürekli göçlerin
evrimle ilgili olduğunu söylüyorum,
çünkü buraya bir
bakarsanız,
django_migrations adında küçük bir tablo görürsünüz ve
Django_migrations tablosunda ne yaptığını, bu
göçlerden hangisinin zaten uygulandığını hatırlamaktır.
Bu veri tabanı, geçişlerden geçerken
, diyor ki, “Oh, işte
bu veritabanında henüz yapılmamış
bir tane, bu yüzden veritabanında biraz değişiklik yapmam gerekiyor.”
Bu yüzden yapılan göçleri hatırlar.
Oldukça büyüleyici ve
bu küçük uygulamalarda, bu
konuda her zaman bu kadar zeki olmamıza gerek yok.
Yani bazen yapmak istediğiniz şey
, “Kafası karıştı,
makemigrate'i tekrar çalıştıracağım”,
çünkü gerçekten prodüksiyonu
yönetmiyorsunuz, bunu tekrar tekrar tekrar yapıyorsunuz,
böylece makemigrate'i yeniden çalıştırabilirsiniz.
Ve bunu yapmanın yolu
basitçe dosyayı
silmeniz, bu dosyaları silebilirsiniz.
Sıfır ile başlayan tüm olanları silerdim.
Makemigrate'i yeniden çalıştıracaksanız,
yalnızca makemigrations yeniden çalıştırın,
sıfır ile başlayan tüm olanları
silin ve bu uygulamada
, geçişlerde ve sonra tüm bunlardan
kurtulun ve sonra
makemigrations yeniden çalıştırabilirsiniz ve
models.py dosyanızı okur
ve sonra
geçiş dosyasını yeniden oluşturmak için gerekli tüm işlemleri yapar. Bu veri
tabanı değil. Veritabanının
nasıl oluşturulacağıyla ilgili talimatlar, tamam mı?
Demek bu şekilde göç ediyorsun.
Sıfırdan geçiş çalıştırabilirsiniz,
bu aslında daha kolaydır.
Yani
bir uygulama için göçleri silebilirsiniz ve ben de bunu yaptım,
sadece buradaki bukoneyi
sildim, yaptığım şey buydu ve baştan başladım,
ama tüm göçleri ve
tüm veritabanını ve her şeyi silip
bu davada dosyayı kaldırarak temizleyebilirsiniz çünkü biz 'SQLite çalıştırıyoruz,
sadece
rm db.sqlite dosyasını silin çünkü göç ettikten sonra,
her şey sona erer o dosyada.
O zaman bunu silip süpürüyorsun, yok oluyor.
Şimdi, bir yönetici hesabı ya da
başka bir şey oluşturmuş olabilirsiniz ve onu da sileceksiniz.
Verileri
sileceksin, masaları sileceksin, hepsi gitti.
SQLite hakkında sevdiğim bir şey var,
bu bir dosyayı kaldırıyorsun ve kelimenin tam anlamıyla hepsi gitmiş.
Ve sonra python3 manage.py
göç yeniden çalıştırın ve
tüm göçleri okur ve size güzel,
temiz, mükemmel boş bir veritabanı yapar.
Yani eğer takılıp
kaldıysanız ve verilerinizi kaybetmekten korkmuyorsanız,
bu da başlangıç programcılarının çoğunda
SQLite şeyinizi silip
tekrar geçiş yapmanın bir sakıncası yoktur.
Devam et ve dene.
Dediğim gibi, eğer bir yönetici hesabı
yaptıysan, tekrar yapmalısın,
ama en
azından bu başlangıç uygulamalarında yapabileceğin en kötü şey bu.
Şimdi,
bir veri modelinin nasıl ortaya çıkacağı,
Django models.py dosyasında nasıl
kodlanacağı, göç
işlemlerinin nasıl yapılacağı ve nasıl bir veri tabanı yapılacağı
hakkında konuştuk, şimdi
güncellemek için çalıştırabileceğiniz Python kodundan bahsedeceğiz veritabanında bu modeller.
[ MÜZİK]