2015-01-24 15 views
9

Es scheint, als wäre der Standardwert für Spalten nur auf der ORM-Ebene und legt keinen Standardwert in der Datenbank fest. Zur gleichen Zeit hat der ID-Schlüssel zum Beispiel einen Standard-Modifikator in der Datenbank, der mir sagt, dass es möglich ist, das zu tun, aber nicht sicher, wie?Wie Standard Spaltenwert in der Datenbank mit Django 1.7.3/Postgres Migrationen setzen?

Beispielcode:

class Host(models.Model): 
    name = models.CharField(max_length=255, null=False) 
    created_at = models.DateTimeField(default=datetime.now, blank=True) 

erstellt die folgende Tabelle:

Column |   Type   |       Modifiers       
------------+--------------------------+------------------------------------------------------------- 
id   | integer     | not null default nextval('myapp_host_id_seq'::regclass) 
name  | character varying(255) | not null 
created_at | timestamp with time zone | not null 

Gibt es eine Möglichkeit, die Migration zu haben, setzen default current_timestamp in den created_at Modifikatoren? Wenn nicht, gibt es eine Möglichkeit, SQL-Migrationen zu übertragen? Ich brauche es, weil die Datenbank von anderen Prozessen (z. B. Batch-Prozessen) verwendet wird, die nicht auf der Anwendungsschicht Dinge wie Standardwerte erzwingen wollen.

+0

Gehen Sie zu versuchen, anwenden Methode in 'models.Migration' und lassen Sie es raw sql ausführen. – Isaac

Antwort

8

würde ich Ihren Code in einem RunSQL operation setzen, so etwas wie:

class Migration(migrations.Migration): 

dependencies = [ 
    ('myapp', 'previous_migration'), 
] 

operations = [ 
    migrations.RunSQL("alter table myapp_host alter column created_at set default current_timestamp"), 
] 

denke ich, dieser Ansatz ist sauberer als zu versuchen, apply() außer Kraft zu setzen. Die API erleichtert das Hinzufügen der SQL für die umgekehrte Operation, und da die Migrationsinfrastruktur die Semantik von RunSQL versteht, kann sie möglicherweise bessere Entscheidungen treffen. (Zum Beispiel kann es keine Migrationen über eine Migration mit einer RunSQL Operation quetschen.)

+0

+1 für RunSQL. Ich würde auch empfehlen [überschreibt die ursprüngliche Migration mit dem Parameter state_operations] (http://pankrat.github.io/2015/django-migrations-without-downtimes/#default-values:29c4533310fb23be2fc88d399c969fd7) – Pankrat

0

Das funktionierte für mich. Ich würde noch gerne wissen, ob es sauberere Lösungen:

class Migration(migrations.Migration): 

dependencies = [ 
    ('myapp', 'previous_migration'), 
] 

operations = [] 

def apply(self, project_state, schema_editor, collect_sql=False): 
    cursor = connection.cursor() 
    cursor.execute("alter table myapp_host alter column created_at set default current_timestamp") 
    return super(Migration, self).apply(project_state, schema_editor, collect_sql)