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: https://github.com/django/django/pull/2181 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 %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_h2RAVcSOCxthcd%3DEf4K2P5NqoJs4zc%2BLirBE744McPw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
