it-swarm.asia

django.db.migrations.exceptions.InconsistentMigrationHistory

Kaçtığımda 

python manage.py migrate

django projemde aşağıdaki hatayı alıyorum

Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "/home/hari/project/env/local/lib/python2.7/site-     packages/Django/core/management/__init__.py", line 363, in execute_from_command_line
utility.execute()
File "/home/hari/project/env/local/lib/python2.7/site-packages/Django/core/management/__init__.py", line 355, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/hari/project/env/local/lib/python2.7/site-packages/Django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/Django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/Django/core/management/commands/migrate.py", line 86, in handle
executor.loader.check_consistent_history(connection)
File "/home/hari/project/env/local/lib/python2.7/site-packages/Django/db/migrations/loader.py", line 298, in check_consistent_history
connection.alias,
Django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

Aşağıdaki gibi bir kullanıcı modelim var

class User(AbstractUser):
place = models.CharField(max_length=64, null=True, blank=True)
address = models.CharField(max_length=128, null=True, blank=True)

Peki bunu nasıl çözebilirim?

17
Hari Krishnan

Veritabanınızdaki Django_migrations tablonuz tutarsızlık nedenidir ve tüm taşıma işlemlerini yerel yoldan silmeniz işe yaramaz.

Django_migrations tablosunu veritabanınızdan kesmeniz ve sonra geçişleri yeniden uygulamanız gerekir. İşe yaramalı, ancak o zaman tekrar makemigrasyon yapmaz ve sonra göç eder.

Not: verilerinizin yedeğini almayı unutmayın.

15
Arpit Solanki

Özel bir Kullanıcı modeli kullandığınız için ilk önce yorum yazabilirsiniz. 

INSTALLED_APPS = [
...
#‘Django.contrib.admin’,
...
]

installed_Apps ayarlarınızda. O zaman koş

python manage.py migrate.

Uncomment yapıldığında 

‘Django.contrib.admin’.
37
jackson

Bu sayfadaki cevapların çoğunu içeren sorunu ele alarak başlayalım:

Django'nun göç sistemini doğru kullanıyorsanız, veritabanınızı bırakmak için hiçbir zamanhavekullanmazsınız veshouldsiz geçiş yaptıktan sonra göçleri asla silmezsiniz

Şimdi, sizin için en iyi çözüm, Django ile ne kadar deneyimli olduğunuzu, göç sisteminin ne düzeyde bir anlayışa sahip olduğunuzu ve veritabanınızdaki verilerin ne kadar değerli olduğunu içeren bir dizi faktöre bağlıdır.

Kısacası, herhangi bir geçiş hatasını ele almanın iki yolu vardır.

  1. nuclearseçeneğini al. Warning: bu yalnızca bir seçenektir, yalnız çalışıyorsunuz. Diğer insanlar mevcut göçlere bağlıysa,can'tsadece onları silin.

    • Tüm geçişlerinizi silin ve yeni bir grubu python3 -m manage makemigrations ile yeniden oluşturun. Bu, geçişlerinizdeki bağımlılıklar veya tutarsızlıklar ile ilgili tüm sorunları gidermeniz gerekir.
    • Veritabanının tamamını bırak. Bu, gerçek veritabanı şemanız ile geçiş geçmişinize dayanmanız gereken şema arasındaki uyuşmazlıklar ile karşılaştığınız sorunları ortadan kaldıracak ve geçiş geçmişiniz ile önceki taşıma dosyalarınız arasındaki tutarsızlıklar ile yaşayacağınız sorunları çözecektir [işte bu InconsistentMigrationHistory hakkında şikayetçi].
    • Veritabanı şemanızı python3 -m manage migrate ile yeniden oluşturun
  2. Hatanın nedenini belirleyin ve çözün, çünkü (deneyimden konuşarak) neden neredeyse kesinlikle aptalca bir şeyyoudid. (Genel olarak, göç sisteminin doğru şekilde nasıl kullanılacağının anlaşılmamasının bir sonucu olarak). Yaptığım hatalara göre üç kategori var.

    1. Geçiş dosyalarındaki tutarsızlıklar. Birden fazla kişi bir proje üzerinde çalışırken bu oldukça yaygın bir durumdur. İnşallah değişiklikleriniz çatışmaz ve makemigrations --merge bunu çözebilir, aksi halde birileri bunu çözmek için göçlerini dallanma noktasına geri almak zorunda kalacaktır.
    2. Şemanız ve göç geçmişiniz arasındaki tutarsızlıklar. Bunu yönetmek için birisi ya veritabanı şemasını el ile düzenledi ya da geçişleri sildi. Bir taşımayı sildilerse, değişikliklerini geri alın ve onlara bağırın; diğerleri buna bağlıysa,nevergöçleri silmelisiniz. Veritabanı şemasını el ile düzenledilerse, değişikliklerini geri alın ve sonra onlara bağırın; Django veritabanı şemasını yönetiyor, başkasını değil.
    3. Geçiş geçmişiniz ve geçiş dosyalarınız arasındaki tutarsızlıklar. [Bu, askerin yaşadığı InconsistentMigrationHistory sorunu ve bu sayfaya geldiğimde çektiğim sıkıntı]. Bunu yönetmek için birisi ya Django_migrations masasına el ile bulaşmış ya da bir geçişi silmişafteruygulanmıştır. Bunu çözmek için tutarsızlığın nasıl ortaya çıktığını çözmeniz ve manuel olarak çözmeniz gerekecektir. Eğer veritabanı şemanız doğruysa ve yanlış olan sadece sizin göç geçmişiniz ise, bunu çözmek için Django_migrations tablosunu manuel olarak düzenleyebilirsiniz. Eğer veritabanı şemanız yanlışsa, olması gerektiği gibi olması için manuel olarak düzenlemeniz gerekecektir.

Sorunun tanımına ve seçtiğiniz cevaba göre, yalnız çalıştığınızı, Django için yeni olduğunu ve verilerinizi umursamadığınızı farzedeceğim. Yani nükleer seçenek sizin için doğru olabilir.

Bu durumda değilseniz ve yukarıdaki metin anlamsızca görünüyorsa, yardım istemek için Django Kullanıcının Posta Listesi sormanızı öneririm. İçinde bulunduğun belirli karışıklığı çözmene yardımcı olacak çok yardımcı insanlar var.

İnancınız varsa, bu hatayı nükleerleşmeden çözebilirsiniz!

28
Airs

İşte bu nasıl doğru bir şekilde çözülür.

Projenin içindeki geçişler klasörünüzde aşağıdaki adımları izleyin: 

  1. _Pycache_ ve 0001_initial dosyalarını silin. 
  2. Db.sqlite3 dosyasını kök dizinden silin (tüm verilerinizin kaybolmasına dikkat edin).
  3. terminal çalışmasında: 
      python manage.py makemigrations
      python manage.py geçişi

Voila.

6
Dr. Younes Henni

Boş bir veritabanı üzerinde çalışıyorsanız hızlı bir düzeltme, diğer uygulama geçişlerinden önce account uygulamasının geçişlerini çalıştırıyor olabilir.

$ ./manage.py migrate account

Ve sonra:

$ ./manage.py migrate
2
Duilio

Wagtail 2.0'dan 2.4'e geçiş yaparken bu durumla karşılaştım, ancak üçüncü taraf bir uygulamanın bir geçişi ezdiği/birkaç kez gördüğünüzde/şu anki sürümünüzden öncesonrasında'a taşınıyor.

En azından şok edici derecede basit bir çözüm:

./manage.py migrate
./manage.py makemigrations
./manage.py migrate

başka bir deyişle, makemigrasyonları denemeden önce tek bir göçmenlik yapmak.

1
Rick Westera

Sorun

Django.db.migrations.exceptions.InconsistentMigrationHistory: Geçiş admin.0001_initial, 'default' veritabanında, 0001_initial bağımlılık hesabından önce uygulanır.

Böylece veritabanını öncelikle admin (admin.0001_initial) olmadan geçirebiliriz.

Bağımlılığın taşınmasından sonra, admin.0001_initial öğesini geçirmek için komutları yürütün.

Çözüm

  1. settings.py içindeki 'Django.contrib.admin' dosyasını INSTALLED_APPS'den kaldırın.
  2. komutları çalıştırmak: 

Python manage.py makemigrations uygulama adı

Python manage.py taşıma adı

  1. settings.py dosyasındaki INSTALLED_APPS dosyasına 'Django.contrib.admin' ekleyin.
  2. komutları tekrar yürütün: 

$: Python manage.py makemigrations uygulama adı

$: Python manage.py taşıma adı

1
kun shi

yeni bir Django projesi oluşturup çalıştırdığınızda 

python manage.py geçişi 

Django, varsayılan olarak bir auth_user tablosu ve iki auth_user ile başlayan 10 tablo oluşturacaktır.

abstractUser'dan devralan bir özel kullanıcı modeli oluşturmak istediğinizde, aşağıdaki gibi bir hata mesajı ile karşılaşırsınız:

Django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

Veritabanımın tamamını bırakarak bu sorunu çözüyorum ve yeni bir tane yaratıyorum. Bu da bahsettiğim üç masanın yerini aldı.

1
hcf1425

Bu, yeni bir projede, Django docs tavsiyesine göre özel bir Kullanıcı modeli ekledikten sonra başıma geldi.

Yeni bir projeye başlıyorsanız, varsayılan Kullanıcı modeli sizin için yeterli olsa bile, özel bir kullanıcı modeli oluşturmanız önemle tavsiye edilir.

İşte sorunu çözmek için yaptığım şey.

  1. Db.sqlite3 veritabanını silin.
  2. Uygulama/geçişler klasörünü silin.

@Jackson başına, geçici olarak Django.contrib.admin hakkında yorum yapın.

INSTALLED_APPS = [
...
#‘Django.contrib.admin’,
...
]

Ayrıca urls.py içindeki admin sitesini yorumlayın:

urlpatterns = [
    path('profile/', include('restapp.urls')),
    #path('admin/', admin.site.urls),
]

Yolu açıklamazsanız ('admin /'), çalıştırdığınızda "LookupError: 'admin' etiketli yüklü uygulama yok" hatası alırsınız

python manage.py migrate

Geçişler bittikten sonra, yukarıdakilerin her ikisini de uncomment.

1
user9414732

sadece sqlite dosyasını silin ya da 'python manage.py flush' veritabanını çalıştırın. 

1
Arun

yeni bir proje oluşturduğunuzda ve uygulamasız yaptığınızda, 

python manage.py migrate

django varsayılan olarak 10 tablo oluşturacaktır.

Bundan sonra AbstractUser 'dan miras alan bir müşteri kullanıcısı modeli oluşturmak istiyorsanız, aşağıdaki sorunla karşılaşırsınız:

Django.db.migrations.exceptions.InconsistentMigrationHistory: Göç admin.0001_initial bağımlılığından önce uygulanır. account.0001_inin 'default' veritabanında ilk.

sonunda, Tüm veritabanlarımı atıyorum ve kaçıyorum. 

0
hcf1425

Bu tür bir soruna yol açabilecek kullanıcı hatasının yanı sıra başka bir neden daha var: Django ile ilgili bilinen bir sorun ezilmiş göçler söz konusu olduğunda.

Python 2.7 + Django 1.11'de kusursuz çalışan bir dizi geçişimiz var. makemigrations veya migrate komutunu çalıştırmak her zaman olması gerektiği gibi çalışır, hatta veritabanı yeniden oluşturulduğunda bile (test amacıyla).

Bununla birlikte, bir projeyi Python 3.6'ya taşıdıkça (şu anda aynı Django 1.11 kullanıyorsunuz) 1.11. Aynı göçlerin neden sadece ilk defa çalıştırıldıklarında iyi sonuç verdiğini bulmaya çalışıyorum. Bundan sonra, makemigrations veya hatta sadece migrate komutlarını çalıştırma denemesi hatayla sonuçlanır:

_Django.db.migrations.exceptions.InconsistentMigrationHistory
_

burada göç _foo.0040-thing_, bağımlılığından önce uygulanmaktadır _foo.0038-something-squashed-0039-somethingelse_ (sadece ezilmiş bir göçümüz var ... gerisi çok daha kolaydır).

Beni bir süreliğine rahatsız eden şey, bunun neden sadece Python 'da gerçekleşmesidir. 3. Eğer DB gerçekten tutarsızsa, bunun her zaman olması gerekir. Göçler ilk uygulandıklarında gayet iyi çalışıyor gibi gözüküyorlardı aynı derecede kafa karıştırıcıydı.

Çok araştırdıktan sonra (mevcut Soru-Cevap iş parçacığı dahil), üzerine tökezledim yukarıda bahsedilen Django hata rapor . Squash geçişimiz gerçekten b satırında replaces önekini kullandı (ör. replaces = [(b'', 'foo.0038-defunct'),.......]

b öneklerini replaces satırından çıkardıktan sonra hepsi normal şekilde çalıştı.

0
MartyMacGyver

Hatanız esasen:

Migration "B" is applied before its dependency "A" on database 'default'.

Sanity Check: İlk önce veritabanınızı açın ve 'Django_migrations' tablosundaki kayıtlara bakın. Kayıtlar Kronolojik sıraya göre listelenmelidir (örneğin: A, B, C, D ...).

Hatada listelenen "A" Geçişinin adının veritabanında listelenen "A" geçişinin adıyla eşleştiğinden emin olun. (Geçiş dosyalarını önceden, el ile düzenlediyseniz, sildiyseniz veya yeniden adlandırdıysanız farklılık gösterebilir)

Bunu Düzeltmek için, veritabanındaki göç A'yı yeniden adlandırın veya dosya adını yeniden adlandırın. AMA değişikliklerin ekibinizdeki diğer geliştiricilerin veritabanlarında (veya üretim veritabanında yapılanlarla eşleşmesiyle) eşleştiğinden emin olun

0
Michael Romrell

AUTH_USER_MODE L'yi settings.py içinde ayarlarsanız:

AUTH_USER_MODEL = 'custom_user_app_name.User'

makemigration ve migrate komutlarını çalıştırmadan önce bu satırı yorumlamanız gerekir. Sonra tekrar bu çizgiyi yorumlayabilirsiniz.

0
Erfan Tahriri

İlk Geçiş sonrası Kullanıcı Modeli'ni genişletirseniz, bu Sorun çoğu zaman ortaya çıkar. Çünkü, Soyut kullanıcıyı ne zaman genişletirseniz, e-posta, first_name, vb. Gibi modelde mevcut olan temel alanları oluşturacaktır.

Bu bile Django'daki herhangi bir soyut model için geçerlidir.

Yani bunun için çok basit bir çözüm ya yeni bir veritabanı oluşturmak, sonra da göç uygulamak veya silmek [Bu durumda tüm veriler silinecek.] aynı veri tabanını ve yeniden geçişleri yeniden uygulayın.

0

Bu istisna, standart yerine kendi Kullanıcı modelinizi oluşturmaya çalışırken kendini ortaya koymuşsa, şunu takip edin: talimat
Adım adım bu talimatı izleyerek sorunumu çözdüm: 

  1. Auth.User ile aynı olan özel bir kullanıcı modeli oluşturun, Kullanıcı olarak adlandırın (so Çok-çok sayıda tablo aynı adı saklar) ve db_table = 'auth_user' .__ olarak ayarlayın. (yani aynı tabloyu kullanır)
  2. Tüm göçlerinizi atın
  3. Yeni bir geçiş kümesi yeniden oluşturun
  4. Endişeliysen bir tavuğu, belki iki kişiyi feda et; ayrıca veritabanınızı yedekleyin
  5. Django_migrations tablosunu kısaltın
  6. Yeni geçiş kümesini sahte uygulama
  7. Db_table'ı geri alın, özel modelde diğer değişiklikleri yapın, geçişler oluşturun, uygulayın 

Bunu yapmak için şiddetle tavsiye edilir. yabancı anahtar kısıtlamaları. Bunu dizüstü bilgisayarınızda ve SQLite'da denemeyin. sunucularda Postgres üzerinde çalışmasını bekliyoruz!

0
N.C.

Önce tüm geçişleri ve db.sqlite3 dosyalarını silin ve aşağıdaki adımları izleyin:

$ ./manage.py makemigrations myapp 
$ ./manage.py squashmigrations myapp 0001(may be differ)

Eski taşıma dosyasını ve son olarak silin.

$ ./manage.py migrate
0
shivam singhal