On Thursday, April 2, 2015 at 2:27:51 AM UTC-4, Marc Tamlyn wrote:
>
> Moving them into another module won't make much difference as their
> definition requires Permission and Group and therefore they'd still need to
> import Permission and Group. We'd need an "AbstractAbstractBaseUser" which
>
Apologies, I was confusing abstract base user and abstract user there.
Seems your proposal should work. Have you opened a ticket?
On 2 April 2015 at 14:28, Dan Watson wrote:
> On Thursday, April 2, 2015 at 2:27:51 AM UTC-4, Marc Tamlyn wrote:
>>
>> Moving them into another module won't make much
On Wed, Mar 25, 2015 at 9:37 AM, Thomas Güttler wrote:
> Up to now the validation/cleaning of a attribute can not access the
> value of an other attribute.
>
> The work around is to override the clean() method of the form/model.
>
> A team mate and I talked about it, and we asked ourself, if
> a t
Since I think this can be a useful feature, I'll explain why.
One use case is for validating address forms. We deal with a lot of
them with varying levels of validation based on country, state, zip
code, etc. Sometimes, multiple sets of address fields appear on the
same form. We can't simply reuse
Hi Preston,
On 04/02/2015 10:15 AM, Preston Timmons wrote:
> Since I think this can be a useful feature, I'll explain why.
>
> One use case is for validating address forms. We deal with a lot of
> them with varying levels of validation based on country, state, zip
> code, etc. Sometimes, multiple
On Thursday, April 2, 2015 at 10:38:48 AM UTC-4, Marc Tamlyn wrote:
>
> Apologies, I was confusing abstract base user and abstract user there.
> Seems your proposal should work. Have you opened a ticket?
>
I have:
https://code.djangoproject.com/ticket/24564
https://github.com/django/django/pull/
Yep, I think you're right now. Given existing solutions there's not warrant
enough to add another built-in validation hook.
Preston
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this
On 30 mars 2015, at 23:10, Carl Meyer wrote:
> So it is not true that the Python models are the canonical
> representation of your schema, and the SQL DDL is just a translation of
> them. In fact, your migrations are the (only) canonical representation
> of your schema, which may include things (
As far as I'm aware, we have some code paths which still work in 1.9 which
generate tables directly from the models. We use this when running Django's
own test suite, and it is also used now by djangobench. I haven't looked
into exactly how to turn this into logged SQL rather than run SQL but it
sh
