Agregando restricciones adicionales a los campos en Django

Question

Si bien las subclases db.models.Model, a veces es esencial agregar controles/restricciones adicionales.

E.g. Tengo un modelo Event con start_date y end_date.

Quiero agregar la validación en los campos o el modelo para que end_date > start_date.

¿Cuántas formas posibles de hacer esto?

Al menos sé que esto se puede hacer fuera de models.Model dentro de la validación ModelForm.

¿Pero cómo conectarse a los campos y al models.Model?

Answer 1

No voy a poner restricciones como éstas en el método de guardar, ya es demasiado tarde. Plantear una excepción allí, no ayuda al usuario que ingresó los datos de manera incorrecta, porque terminará como 500 y el usuario no recibirá el formulario con errores, etc.

Realmente debería verificar para esto en el método de limpieza Forms/ModelForms y generar un ValidationError, entonces form.is_valid() devuelve falso y puede enviar los errores en el formulario de vuelta al usuario para su corrección.

También tenga en cuenta que desde la versión 1.2, Django ha tenido Model Validation.

Se vería algo como esto:

class Foo(models.Model): 
    # ... model stuff... 
    def clean(self): 
     if self.start_date > self.end_date: 
      raise ValidationError('Start date is after end date') 

Answer 2

Hágalo dentro de su Guardar método de su modelo:

def save(self, *args, **kwargs): 
    if(self.end_date > self.start_date): 
     super(Foo, self).save(*args, **kwargs) 
    else: 
     raise Exception, "end_date should be greater than start_date" 

Answer 3

Como @stefanw dice, es mejor experiencia de usuario para comprobar en el método de limpieza de la forma.

Esto es suficiente si está seguro de que no hay, y nunca existirá, otra forma de cambiar el valor. Pero ya que rara vez se puede estar seguro de que, si la consistencia de base de datos es importante, se puede añadir otro cheque (además de la forma), uno de:

• La manera más fácil y base de datos independiente es en el modelo de guardar método como @ umnik700 dijo. Tenga en cuenta que esto aún no impide que otros usuarios de la base de datos (otra aplicación o la interfaz de administración) creen un estado incoherente.

• Para estar 'completamente' seguro de que la base de datos es coherente, puede agregar una restricción de nivel de base de datos. P.ej. puede crear una migración con RunSQL y SQL, algo similar (no probado):

  migrations.RunSQL('ALTER TABLE app_event ADD CONSTRAINT chronology CHECK (start_date > end_date);') 
  

  (No se ha probado). Esto puede depender de la base de datos, lo cual es una desventaja, por supuesto.

En su ejemplo, no es probablemente vale la pena (tiempos de inicio incorrecto/final sólo se ven un poco raro, pero sólo afectan el único evento inconsistente), y que no quieren cambios en el esquema manuales. Pero es útil en casos donde la consistencia es crítica.

EDIT: También puede simplemente guardar la hora de inicio y la duración, en lugar de las horas de inicio y fin.

Answer 4

A partir de hoy, tanto postgres 9.4 como MS SQL Server >= 2008 admiten restricciones de comprobación en sql. Además de esto, hay django issue 11964 que parece estar listo para su revisión desde ayer, así que espero que veamos esto integrado en django 2. El proyecto rapilabs/django-db-constraints parece implementar esto también.