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
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.
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
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.
>
>
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
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
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
> 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
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
> (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
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
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
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
13 matches
Mail list logo
