L'app Django 1.8 utilizza un'app di terze parti (django-avatar) il cui modello contiene un ImageField. Sto anche utilizzando un DEFAULT_FILE_STORAGE personalizzato (S3BotoStorage da django-storages-redux) nel mio settings.py del mio progetto. Di conseguenza, ogni volta che corro manage.py migrate, ottengo questo avviso circa l'avatar app:Django "modifiche non riflesse in una migrazione" con ImageField e memoria personalizzata
I suoi modelli sono dotati di cambiamenti che non sono ancora riflessi in una migrazione, e quindi non saranno applicate. Esegui "manage.py makemigrations" per effettuare nuove migrazioni, quindi riesegui "manage.py migrate" per applicarle.
... perché avatar's initial migration riferimenti FileSystemStorage predefinito di Django. makemigrations esecuzione crea un nuovo 0002 di migrazione nel avatar app, per fare memoria del suo ImageField corrispondono alla mia impostazione del progetto:
...
migrations.AlterField(
model_name='avatar',
name='avatar',
field=models.ImageField(storage=storages.backends.s3boto.S3BotoStorage(), max_length=1024, upload_to=avatar.models.avatar_file_path, blank=True),
),
Il problema è, questa nuova migrazione viene creato in avatar installato in site-packages di python, al di fuori il mio progetto (quindi fuori controllo git, non disponibile per la distribuzione, ecc.).
Qual è il modo corretto di gestire le migrazioni per un'app di terze parti che utilizza un ImageField (o FileField) in un progetto con DEFAULT_FILE_STORAGE personalizzato? Ho preso in considerazione:
Basta ignorare l'avviso. La migrazione per modificare lo spazio di archiviazione non è in realtà lo influenza lo schema del DB e poiché il DEFAULT_FILE_STORAGE del mio progetto è stato S3BotoStorage dall'inizio, non è necessaria alcuna migrazione dei dati.
Utilizzare settings.MIGRATION_MODULES per spostare le migrazioni di avatar nel mio progetto. (E poi accuratamente la porta su ogni futuro avatar migrazione verso la mia copia - che sembra soggetto a errori.) [EDIT:. this comment sulla mailing list django-utenti suggerisce che questo è l'approccio sbagliato]
Chiedi i manutentori di django-avatar (o django-storages-redux) per cambiare ... cosa? (BTW, S3BotoStorage è già deconstructible - non è questo il problema.)
Oppure ...?
Hey medmunds, sono l'attuale manutentore di django-avatar e vorrei anche sapere la risposta a questo. Pensi che la creazione di un'altra migrazione che modifichi l'attributo 'ImageField.storage' per fare riferimento a' settings.AVATAR_STORAGE' possa impedire questo? – grantmcconnaughey
Hey Grant, grazie per il pacchetto! Quindi, dovresti aggiungere una migrazione dello schema a django-avatar e modificarlo manualmente per avere qualcosa come 'storage = get_storage_class (settings.AVATAR_STORAGE)()'?Penso che potrebbe risolvere il mio problema, ma dovresti ricordarti di modificare ogni futura schemamigrazione di django-avatar allo stesso modo. Inoltre, * potrebbe * causare problemi alle persone che provano veramente a migrare da una memoria all'altra, perché non congelerebbe lo stato al momento della migrazione (forse - non sono sicuro di questo). – medmunds
C'è qualche discussione sulle migrazioni e gli archivi nel tracker Django ([22373] (https://code.djangoproject.com/ticket/22373) e [22337] (https://code.djangoproject.com/ticket/22337)), ma nulla di tutto ciò nel contesto di app di terze parti. Mi chiedo se sarebbe utile sollevare il problema laggiù? – medmunds