Thanks a lot tim! that will be really helpful!
On Wed, Mar 11, 2015 at 6:42 AM, Tim Graham wrote:
> It's up to you to convince the value in your ideas. The more specific you
> can be, the easier we'll be able to give feedback. Here's a related ticket
> about using class-based views in contrib.au
Great stuff Erik. This will greatly simplify how we validate passwords!
One thing I'd like to note is that it is extremely frustrating when a form
fails validation with an error message, you fix that particular problem,
and you're given the next error message. Ideally, all validators would run
It's up to you to convince the value in your ideas. The more specific you
can be, the easier we'll be able to give feedback. Here's a related ticket
about using class-based views in contrib.auth which may be helpful:
https://code.djangoproject.com/ticket/17209
On Monday, March 9, 2015 at 2:05:3
On Tuesday 10 March 2015 19:39:19 Michael Manfre wrote:
> I agree with Tim.
>
> I would support refactoring inspectdb so that it would be easier for anyone
> to subclass the command and add additional logic to the introspection
> process.
+1.
Shai.
One point which may be relatively easy and valuable is to get Django to
support backend-provided tests, and do the final clean-up of backend-specific
tests from the general test suite. That is, put all the postgres-specific tests
somewhere in django.db.backends.postgresql_psycopg2 etc, and have
Hi Erik and all,
The approach, indeed, seems fine, which is far from trivial. Some details, of
course, still need to be worked out. I like Aymeric's suggestion re help_text
-- I would take that one step further and allow every validator to give its
own list of requirements.
I have one "devil's
I agree with Tim.
I would support refactoring inspectdb so that it would be easier for anyone
to subclass the command and add additional logic to the introspection
process. Alternatively, moving much of the logic out to a function that
returns a JSON representation of the database that inspectdb u
