Merging GSoC 2013 - Validation Refactor

111 views
Skip to first unread message

Russell Keith-Magee

unread,
Jan 18, 2014, 11:50:35 AM1/18/14
to Django Developers
Hi all,

After a long delay, I'm finally ready to merge the result of Christopher Medrela's 2013 Summer Of Code Project - a refactor of Django's validate management command.

A huge thanks to Christopher for his excellent work over the summer - he made my job as mentor very easy.

For those that didn't follow along with the project itself - Django's validate management command was a single monolithic block of code that checked for name collisions, certain allowable attribute values, and so on. It wasn't extensible in any way.

The purpose of this refactor was to break this monolithic method up into smaller parts, and along the way, provide a way for other apps/libraries to hook in and provide their own checks. So, for example, GenericForeignKeys now get validation support - this wasn't previously possible because they are part of a contrib app, and therefore couldn't be referenced in the core codebase.

So - if you've got a field, model base class or model manager that needs custom validation that you'd like to be reported in the same way as ./manage.py validate has historically reported, you now have a way to do so.

Or, if you've got some other system check that you'd like to perform (for example, performing a security audit), you can hook in to the same tools.

As part of this refactor, we've also dealt with the manifold overloading of the term "validate" in Django's codebase. We've deprecated "validate" in preference for the "check" command.

A side effect of this is that the version update checks introduced in 1.6 are now guaranteed to run every time you do runserver. To make sure you aren't needlessly bothered once you've dealt with these issues, individual message types can be silenced. So, for example, when you do a version update, you may be warned about a change; once you're satisfied that you've met that requirement, you can silence that error and never see it again.

We also allow for different severity levels: DEBUG, INFO, WARNING, ERROR, CRITICAL. This provides a lot more options for reporting problems that aren't show-stoppers, but probably warrant attention (e.g., easily identifiable performance issues).

I've created a clean PR based on a rebased version of the code that has been brought up to date with trunk:


There are a still a couple of minor issues that may need to be addressed - in particular, I want to do a cleanup of the language for the messages themselves, and the documentation would probably benefit from another pair of eyes. However, I'm happy with the way the core has shaken out; I want to get it into core so it gets more exposure.

Tim's review a couple of days ago also pointed out a couple of interesting features (in particular, adding a command-line flag to silence specific warnings) which might be nice to have, but shouldn't affect core functionality.

Barring objections, I'm planning to land this in time for the 1.7 alpha (so Andrew - no cutting releases until I've had a chance to push the merge button :-)

So - final chance for comments and feedback before this lands!

Yours,
Russ Magee %-)

Russell Keith-Magee

unread,
Jan 19, 2014, 10:13:09 PM1/19/14
to Django Developers
Hi all,

For notification purposes - this has been committed as of d818e0c, ready for 1.7 alpha.


The final commit integrated a bunch of suggestions from a couple of reviewers, some Python 3 fixes, and a slight rework of the Django 1.6 TEST_RUNNER compatibility fix (to reduce the number of false positives that check was providing).

On the TODO list before 1.7 final:

 * There's some ongoing discussion about the best way to integrate the check registration process with the new app-loading ready() method; 

 * The text of the actual messages raised by the checks framework needs a final audit.

 * There's lots of room for improvement in documentation, including an index of checks that Django will raise

Tim has also suggested some possible improvements to the process for silencing check messages.

Thanks again to Christopher Medrela for his excellent work in GSoC 2013, without whom none of this would have been possible.

Yours,
Russ Magee %-)

Reply all
Reply to author
Forward
0 new messages