Code

Changes between Version 5 and Version 6 of SummerOfCode2011


Ignore:
Timestamp:
03/09/11 18:36:01 (3 years ago)
Author:
ramiro
Comment:

Added initial description of Validation functionality revamping idea

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode2011

    v5 v6  
    206206See also: 
    207207 * #8579 
     208 
     209=== Validation functionality revamping === 
     210* '''Complexity:''' Moderate 
     211 
     212This ideas has some overlap with the [#best-practices-updates previous one]. 
     213 
     214Django currently has a validation framework: A static, monolithic  collection of checks implemented in Python code that is automatically executed  before the ''syncdb'' or ''runserver'' commands and whose functionality is available through the [http://docs.djangoproject.com/en/dev/ref/django-admin/#validate 'validate'] management command. It is given the chance to inspect the model definitions of installed apps and can flag errors to the developer during the development phase. 
     215 
     216But there is the possibility to expand it to increase its usefulness. These are some ideas that have been proposed so far: 
     217 
     218 * Add the concept of warnings, as opposed to the current hard errors. This would mean a refactoring of the code into a more generic framework so we can defer validation to individual fields or to the database backend, as required. Some scenarios where it would be of help to developers by pointing  some non-fatal but potential problems: 
     219  * Some database backends have some reserved names for database columns (e.g. Oracle doesn't accept columns named ''date'' or ''number'') 
     220  * Some fields names chosen by the developer can clash with names of  [http://docs.djangoproject.com/en/dev//ref/models/querysets/#field-lookups ORM query lookups]. 
     221 
     222* Provide a mechanism so applications can hook and get their own validation code run at this point. See for example ticket #8579. 
     223 
     224See also: 
     225 * #8579