InvalidBasesError: Impossibile risolvere basi per [<ModelState: 'users.GroupProxy'>]

Question

Quando eseguo test ottengo questo errore durante l'inizializzazione del database:

django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'users.GroupProxy'>] 
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth) 

Ho creato questo proxy per il modello contrib.auth Gruppo inseriscilo nella mia app in django admin:

class GroupProxy(Group): 
    class Meta: 
     proxy = True 
     verbose_name = Group._meta.verbose_name 
     verbose_name_plural = Group._meta.verbose_name_plural 

Quindi, cosa posso fare per risolvere questo problema?

Answer 1

Dopo un sacco di scavare su questo l'unica cosa che ha funzionato per me è stato

comment out the offending apps, run migrations, then add them in again.

Un semplice trucco, ma si spera che aiuta qualcuno.

Answer 2

Hai provato a eseguire manage.py makemigrations <app_label> sulla tua app prima di eseguire i test?

Inoltre, controllare se l'app che modello (i) si sta provando a Proxy è inclusa in INSTALLED_APPS.

Answer 3

Se ciò accade solo quando è in esecuzione python manage.py test (forse perché sono già state effettuate le migrazioni necessarie), è necessario dire esplicitamente che contrib.auth non deve migrare nello MIGRATION_MODULES del modulo delle impostazioni.

MIGRATION_MODULES(
     'auth': "contrib.auth.migrations_not_used_in_tests", 
) 

Answer 4

ho incontrato questo problema, e come commentando la modella non è davvero una soluzione, ho trovato che l'impostazione non documentata auto_created = True alla classe Meta renderà Django ignorarlo.

class GroupProxy(Group): 

    class Meta: 
     proxy = True 
     auto_created = True 

Answer 5

Ho avuto questo problema dopo aver rinominato la tabella padre di un gruppo di miei modelli proxy. Ho risolto il problema:

1. Elimina il file di migrazione con la modifica del nome per la tabella padre.
2. Utilizzando il terminale Postgres, ho rinominato la tabella padre con il nome precedente.
3. Ran makemigrations e migrate nuovo

Answer 6

semplice fatto di creare una directory migrations alla radice della vostra applicazione (in modo users/migrations/ nel tuo caso) e l'aggiunta di un file vuoto __init__.py potrebbe risolvere il problema. Almeno lo ha fatto per me quando ricevevo lo stesso errore.

Ma è meglio utilizzare makemigrations per la tua app, come suggerito da @zenofewords sopra. Questo creerà la directory per te E genererà migrazioni per i tuoi modelli proxy.

Why does Django create migration files for proxy models?

i test sono alla ricerca di quelle migrazioni e non stanno trovando loro.

Answer 7

Ho anche affrontato questo problema (dopo aver eseguito un modello complesso di ereditarietà).Uno dei miei migrazioni conteneva

migrations.CreateModel(
    name='Offer', 
    fields=[ 
     # ... 
    ], 
    options={ 
     # ... 
    }, 
    bases=('shop.entity',), 
), 

ho cancellato shop.Entity modello del tutto, ma la migrazione è stata Referencing in attributo bases. Quindi ho appena cancellato bases=('shop.entity',) e funziona. Probabilmente interromperà l'opportunità di migrare dall'inizio, ma almeno permetterà di migrare ulteriormente.

Un altro consiglio potrebbe essere: andare direttamente al codice django e ispezionare cosa causa problemi "basi". Vai a django/db/migrations/state.py e aggiungere un punto di interruzione:

try: 
    bases = tuple(
     (apps.get_model(base) if isinstance(base, six.string_types) else base) 
     for base in self.bases 
    ) 
except LookupError: 
    print(self.bases) # <-- print the bases 
    import ipdb; ipdb.set_trace() # <-- debug here 
    raise InvalidBasesError("Cannot resolve one or more bases from %r" % (self.bases,)) 

Answer 8

Dopo aver trascorso la maggior parte di questo pomeriggio, cercando di risolvere questo errore io stesso, passando per ogni miscela immaginabile di 'commentando le app', 'lasciando cadere le tabelle' e far cadere interi database I ho riscontrato che il mio problema era causato da una semplice mancanza di una cartella "migrazioni" e un file __ init__.py all'interno di detta cartella.

Una delle risposte più vecchie che era corretta ora non è più corretta in quanto hanno risolto il problema menzionato here.

Controllare ogni directory che contiene il modello menzionato in 'init.py' e dovrebbe andare via.

Probabilmente non risolverà il caso di tutti ma ha aiutato il mio.