#19126: runserver versus model validation
--------------------------------------------+--------------------
Reporter: direvus | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Management commands) | Version: 1.3
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------------+--------------------
I recently encountered a frustrating little issue in one of my apps. I
wasn't able to run the development server because of a non-critical model
validation failure.
The error was '"ordering" refers to "split_code", a field that doesn't
exist.'
In several of my models, "ordering" refers to a field which isn't part of
the main model definition, but *is* added to the query set by a custom
default Manager. So in practice (when I run it under mod_wsgi) the
ordering works exactly as intended. This is a case where the model fails
to validate, but actually works properly in a live-fire situation.
Perhaps the model validation is too strict in this case, but I can
understand why. It would probably be a lot of fuss to try to make it
clever enough to detect additional fields that are pulled in by the
queryset on the Manager. But there's a broader issue in that *any* model
validation failure, no matter how unimportant, is enough to stop the
development server from working with an "Unhandled exception" in 1.3.1.
I think it's fine that I get a message about the "ordering" definition,
but I don't think it should be a showstopper.
There are few different ways to get past this. My suggestion would be
that when executing "runserver", we should catch CommandErrors coming out
of 'validate', report them, and then keep on trying to run the server
anyway.
I've included a patch along these lines.
Other options include
* teach 'validate' to recognise fields that are included by the default
Manager's queryset,
* teach 'validate' to differentiate between errors that are critical in
nature, and those that really only need to be warnings,
* allow SQL expressions in 'ordering', not just field names, so that the
custom Manager field isn't necessary in the first place.
... but they all seem like a lot of effort.
Thanks for your time.
--
Ticket URL: <https://code.djangoproject.com/ticket/19126>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
