Se hai un codice personalizzato per i modelli (i validatori personalizzati e i campi personalizzati sono esempi), Django Migrations li importerà direttamente nei file di migrazione. Un esempio:
file web / models.py
def validate_power(self, power):
if power == 'fly':
raise ValidationError('Heroes cannot fly!')
class Hero(Model):
power = CharField(max_length=30, validators=[validate_power])
Nel file di migrazione, ci sarà:
file web / migrations / 0001_initial.py
class Migration(migrations.Migration):
operations = [
migrations.CreateModel(
name='Hero',
fields=[
('id', models.AutoField(verbose_name='ID', serialize=False, primary_key=True, auto_created=True)),
('power', models.CharField(max_length=30, validators=[web.models.validate_power])),
],
),
]
Il validatore viene importato direttamente dalla base di codice. Ciò significa che se dovessi cambiare un validatore, dovrò assicurarmi che sia compatibile con le versioni precedenti, fino a quando manterrò quella migrazione (che potrebbe essere per sempre). Lo stesso accade ai campi personalizzati, il che è peggio per mantenere la retrocompatibilità perché a volte è necessario modificare (o semplicemente voler cambiare) come si memorizzano i dati, gestirli, ecc. Se si modifica la modalità di memorizzazione dei dati, ad esempio, potrebbe ha senso cambiare i validatori e quindi tutte le migrazioni precedenti che si basavano sul validatore non funzioneranno più (a meno che non si cambi il codice di migrazione, e che potrebbero essere molti file, e anche il cambiamento del codice di migrazione non dovrebbe essere necessario).
Quindi, questa idea di importare direttamente dal codebase lega i dati al codice. Non dovremmo sforzarci di tenerli separati? Forse dovremmo attenerci alle migrazioni SQL raw? È possibile risolvere questo problema senza utilizzare le migrazioni SQL raw? I dati vincolanti codificano un prezzo che vale la pena pagare per mantenere SQL a distanza?