Re: Reorganising management/validation.py

2008-02-24 Thread Malcolm Tredinnick
On Sun, 2008-02-24 at 22:54 -0600, Adrian Holovaty wrote: [...] > With that in mind, and also considering the fact that the > queryset-refactor branch has gone on for a long time, I suggest that > this reorganization be shelved until after queryset-refactor is > merged. I don't see a huge reason

Re: Reorganising management/validation.py

2008-02-24 Thread Adrian Holovaty
On Sun, Feb 24, 2008 at 9:21 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Since Marty pointed out the old thread, which I'd not noticed at the > time, I've been thinking about Adrian's fairly consistent objection to > stuff in memory we don't need. I can work around that, too, I think.

$$$$$$$$$www.200836.com----Beijing/peking 2008 Olympic Games Five volunteers named December 2007 Volunteer Stars

2008-02-24 Thread 200836 beijing
$www.200836.com--- why we buy Peking 2008 Olympic Games― souvenirs 1 low price 2 best quality-- licensed products by Peking Organizing Committee 3 many products to choose 4 most precious―limited circulation 5,we accept all payment methods,such as paypal,credit card, telegraphic transfe

Re: Reorganising management/validation.py

2008-02-24 Thread Malcolm Tredinnick
On Mon, 2008-02-25 at 11:27 +0900, Russell Keith-Magee wrote: [...] > For the record, I'm +1 on (2). syncdb and runserver both run validate > over the model definitions; given that barrier, I would have thought > that the chances of getting a broken model definition on a live > mod_python/wsgi de

Re: Reorganising management/validation.py

2008-02-24 Thread [EMAIL PROTECTED]
sanity_check() sounds like, well, a sane way of doing this! +1 from me -Eric Florenzano On Feb 24, 5:30 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > In django/core/management/validation.py we have a bunch of checks for > various Things That Can Go Wrong(tm) when constructing a model. > >

Re: Reorganising management/validation.py

2008-02-24 Thread Russell Keith-Magee
On Mon, Feb 25, 2008 at 10:14 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On 2/24/08, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > A few things I'm working on now end up requiring additions to this list > > and every time I open up the file I want to reorganise it to makes > > thin

Re: Reorganising management/validation.py

2008-02-24 Thread Marty Alchin
On 2/24/08, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > A few things I'm working on now end up requiring additions to this list > and every time I open up the file I want to reorganise it to makes > things easier to maintain. The main point is that almost all of these > validation checks a

Re: Reorganising management/validation.py

2008-02-24 Thread Malcolm Tredinnick
On Sun, 2008-02-24 at 16:53 -0800, Ivan Illarionov wrote: > Thank you. Hope to see this soon in qs-rf :). I am forced to use some > ugly hackish Just to manage expectations here: I'm going to be some refactoring of existing functionality. I'll keep your needs in mind so as not to rule it out as

Re: Reorganising management/validation.py

2008-02-24 Thread Ivan Illarionov
> Only one of the current field checks is backend specific, although I > suspect there are some Oracle-specific checks that might be handy. Most > of them are completely generic (e.g. DecimalField must have a max_length > feature). There are certainly some backend-specific "Things That Can Go Wron

Re: Reorganising management/validation.py

2008-02-24 Thread Malcolm Tredinnick
On Sun, 2008-02-24 at 16:22 -0800, Ivan Illarionov wrote: > > > (2) Put a method on each field (and Options and maybe Model if needed) > > called something like sanity_check() -- we shouldn't use validate() as > > that means something else at that level -- and call sanity_check() > > manually fr

Re: Reorganising management/validation.py

2008-02-24 Thread Ivan Illarionov
> (2) Put a method on each field (and Options and maybe Model if needed) > called something like sanity_check() -- we shouldn't use validate() as > that means something else at that level -- and call sanity_check() > manually from management/validation.py. Could this sanity_check() belong to the

Re: Reorganising management/validation.py

2008-02-24 Thread Malcolm Tredinnick
On Sun, 2008-02-24 at 18:42 -0500, Max Battcher wrote: > Malcolm Tredinnick wrote: > > Anybody feel strongly that we should go for option (1)? > > I think I'm -0 on option 1, but thought that it should be mentioned that > Warnings complicate option 1. The obvious example being that darned > D

Re: Reorganising management/validation.py

2008-02-24 Thread Max Battcher
Malcolm Tredinnick wrote: > Anybody feel strongly that we should go for option (1)? I think I'm -0 on option 1, but thought that it should be mentioned that Warnings complicate option 1. The obvious example being that darned DeprecationWarning currently seen on trunk for every remaining instan

Reorganising management/validation.py

2008-02-24 Thread Malcolm Tredinnick
In django/core/management/validation.py we have a bunch of checks for various Things That Can Go Wrong(tm) when constructing a model. A few things I'm working on now end up requiring additions to this list and every time I open up the file I want to reorganise it to makes things easier to maintai