| 208 | |
| 209 | === Validation functionality revamping === |
| 210 | * '''Complexity:''' Moderate |
| 211 | |
| 212 | This ideas has some overlap with the [#best-practices-updates previous one]. |
| 213 | |
| 214 | Django 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 | |
| 216 | But 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 | |
| 224 | See also: |
| 225 | * #8579 |