Re: Making max_length argument optional

[Aymeric Augustin]

On 22 sept. 2015, at 07:57, Podrigal, Aron  wrote:
> We will be using max_length=255 or 128 for the default as Shia proposed.
> 
Would you mind giving a few hours for other contributors to react? I was asleep 
while you were having this discussion; not every contributor is hooked to 
django-developers, especially technical board members.
> BTW how is this handled by integer_ranges on per database backend?
> 
I was asking myself the same question after seeing 
https://code.djangoproject.com/ticket/14094#comment:15 
. I don’t know; perhaps 
it doesn’t! It’s worth investigating.

-- 
Aymeric.




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/ECA9C917-6FB8-467B-97DC-9E4FE970BC9B%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

Ok, I'll wait for other contributors to react.
On Sep 22, 2015 2:03 AM, "Aymeric Augustin" <
aymeric.augus...@polytechnique.org> wrote:

> On 22 sept. 2015, at 07:57, Podrigal, Aron 
> wrote:
>
> We will be using max_length=255 or 128 for the default as Shia proposed.
>
> Would you mind giving a few hours for other contributors to react? I was
> asleep while you were having this discussion; not every contributor is
> hooked to django-developers, especially technical board members.
>
> BTW how is this handled by integer_ranges on per database backend?
>
> I was asking myself the same question after seeing
> https://code.djangoproject.com/ticket/14094#comment:15. I don’t know;
> perhaps it doesn’t! It’s worth investigating.
>
> --
> Aymeric.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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/ECA9C917-6FB8-467B-97DC-9E4FE970BC9B%40polytechnique.org
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CANJp-yhdepHYgQ9eUCWwFEtVBsDjA8JbAroOTBGM_ssAxWGhUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANNOTATIONS WORKING

[varun naganathan]

The bug is already reported.I'm trying to fix it.so just wanted to be oriented 
in the workflow to fix the bug.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/7a09753f-d211-4485-8d86-5dbfecf15a9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DJango 1.8 test case fails with IntegrityError error

[Jose Paul]

Dear All,

I am trying to run DJango 1.8 test cases with DB2 


Several insert statement fails 

Here is the insert command generated by test case.

INSERT INTO "AUTH_USER" ("PASSWORD", "LAST_LOGIN", "IS_SUPERUSER", 
"USERNAME", "FIRST_NAME", "LAST_NAME", "EMAIL", "IS_STAFF", "IS_ACTIVE", 
"DATE_JOINED") VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s)

Value : (None, None, True, u'superuser', None, None, None, False, True, 
u'2015-09-17 12:31:09.562000')

ibm_db_dbi::IntegrityError: Statement Execute Failed: [IBM][CLI 
Driver][DB2/NT] SQL0407N  Assignment of a NULL value to a NOT NULL column 
"TBSPACEID=2, TABLEID=24, COLNO=1" is not allowed.  SQLSTATE=23502\r 
SQLCODE=-407


Except last_login none of the field are nullable .
But still DJango testcase generate insert statement  as above and pass None 
as value which fails .

Why this happens ?.
Why correct non null values are not generated for non null field .

Please help .Thanks ,
Jose

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/3800220f-e636-400d-8574-103730ed3c66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Remco Gerlich]

On Mon, Sep 21, 2015 at 11:49 PM, Podrigal, Aron 
wrote:

> We're not talking about representing all CharFields as TEXT, it is about
> choosing a sane length as the default for the varchar datatype. So if you
> would not specify max_length, for MySQL it would be varchar(255), for
> oracle it would be varchar(4000 / bytes_per_char_for NLS_CHARACTERSET) and
> for PostgreSQL it would be just VARCHAR without a length.
>

I feel that IF a "sane length as the default" exists, then it must be the
same for all database backends. The errors you get from a ModelForm on a
web page shouldn't change depending on the database backend!

Maybe django.contrib.postgres could have a ArbitraryLengthCharField?

Greetings,
Remco Gerlich

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAFAGLK1%2BEsapoVNLr7Cgz4YqY0ykTiNWD2zNLfC%2Bce446Pzuxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANNOTATIONS WORKING

[varun naganathan]

The bug is already reported and the triage stage is accepted.I'm in the path of 
trying to fix the bug so kind if needed guidance on how to pursue solving it .
Thanks 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/c334603c-25ee-4e23-a099-ab03d7ca4b58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Tim Chase]

On 2015-09-22 07:49, Aymeric Augustin wrote:
> > And for your concern, there will be a MaxLengthValidator added to
> > the validators to validate the users input does not exceed the
> > database backends maximum length just like when you set
> > max_length explicitly.
> 
> This isn’t possible in a project that uses multiple databases, say
> PostgreSQL and Oracle. The form layer cannot say which length is
> correct because it has doesn’t know in what database the data will
> be saved.

Could this be resolved with allowing max_length=None (or some other
atom such as just object() that would have a unique id() that could
be tested with "is") to specify that the back-end uses the max-allowed
value? For Postgres, this would then use VARCHAR() with no limit,
while on MySQL, that could be 255 or whatever.

One could then include a helper function that would use the current
settings to check a string (such as from a form) to ensure that it
doesn't exceed the field's database-specific max-length (or whatever
the specified max-length value is).

-tim




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/20150922065843.37699cb6%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: DJango 1.8 test case fails with IntegrityError error

[Shai Berger]

On Tuesday 22 September 2015 09:39:17 Jose Paul wrote:
> Dear All,
> 
> I am trying to run DJango 1.8 test cases with DB2
> 
> 
> Several insert statement fails
> 
> Here is the insert command generated by test case.
> 
> INSERT INTO "AUTH_USER" ("PASSWORD", "LAST_LOGIN", "IS_SUPERUSER",
> "USERNAME", "FIRST_NAME", "LAST_NAME", "EMAIL", "IS_STAFF", "IS_ACTIVE",
> "DATE_JOINED") VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
> 
> Value : (None, None, True, u'superuser', None, None, None, False, True,
> u'2015-09-17 12:31:09.562000')
> 
> ibm_db_dbi::IntegrityError: Statement Execute Failed: [IBM][CLI
> Driver][DB2/NT] SQL0407N  Assignment of a NULL value to a NOT NULL column
> "TBSPACEID=2, TABLEID=24, COLNO=1" is not allowed.  SQLSTATE=23502\r
> SQLCODE=-407
> 
> 
> Except last_login none of the field are nullable .
> But still DJango testcase generate insert statement  as above and pass None
> as value which fails .
> 
> Why this happens ?.

Does the DB2 backend has the feature interprets_empty_strings_as_null set to 
True?

If it does, it should also make sure to generate the CharField's datbase 
columns as nullable, whether or not the fields are defined null=True.

HTH,
Shai.

Re: Making max_length argument optional

[Collin Anderson]

If anyone's curious, the mysql situation is as crazy as you might expect. :)

The max is only determined only by the total row size (65,535 bytes) and
the index size (767 bytes default).

Mysql defaults to only allowing 3-byte (no emoji) unicode characters, so
65,535/3=21,845 max across the entire row (the sum of all of the maxes of
all char/varchar columns), and each indexed field only gets 767/3=255
characters by default.

If you change to 4-byte unicode characters, (which you should, but django
doesn't really help you out #18392), your max_lengths can add up to
65,535/4=16,383 characters, and if you want the field to be indexed, you
only get 191 characters (using the default index size). It's possible to
only index the first 767/4=191 characters of the field, but django doesn't
really support that.

Basically, 255 works pretty well by default, allowing 65,535/3/255=85
3-byte fields per row, and indexes just work if you stick to the default
settings.

https://dev.mysql.com/doc/refman/5.0/en/char.html
https://code.djangoproject.com/ticket/18392


On Tue, Sep 22, 2015 at 1:56 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hi Shai,
>
> On 22 sept. 2015, at 04:22, Shai Berger  wrote:
>
> > I'd solve the "need to specify" issue by setting a default that is
> > intentionally smaller than the smallest (core) backend limitation, say
> 128.
>
> I would pick the highest value supported by all core backends (probably 255
> for MySQL, unless there’s something about indexes and multi-byte encodings
> that I forget) in order to minimize the need to increase it.
>
> If we go for a lower value, I suggest to pick something totally arbitrary
> like
> 100 to make it clear that it isn't a technical limitation.
>
> > I"d make an "unlimited length text field" a new type of field,
> explicitly not
> > supported on MySql and Oracle; and I'd suggest that it can live outside
> core
> > for a while. so we may get an impression of how popular it really is.
>
> The main use case seems to be “VARCHAR() on PostgreSQL”. What about
> defining a
> slight variant of CharField in django.contrib.postgres that merely makes
> the
> max_length argument default to None?
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" 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/17C37814-E6A8-4E27-B590-BF9FFF42CB20%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAFO84S5TUwLPf%3DRrGXL4%3Dvf3647CufOsijiznttVQF%2BxYHaBFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANNOTATIONS WORKING

[Tim Graham]

What's the ticket number?

On Tuesday, September 22, 2015 at 7:56:04 AM UTC-4, varun naganathan wrote:
>
> The bug is already reported and the triage stage is accepted.I'm in the 
> path of trying to fix the bug so kind if needed guidance on how to pursue 
> solving it . 
> Thanks 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/48fc8759-5934-4673-ac81-ad1966317f6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Anjul Tyagi(geety)]

How do I represent the changes the I made in the documentation, I created a 
branch of the ticket on my local django repository but now should I create a 
.txt file with the changes or create two new .txt files, one representing the 
original documentation and other representing the edited version and then share 
the "diff" file of the two ?


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/26dc8ade-d87f-4656-910d-9e3e2fa3cb92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Tim Graham]

See if 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/working-with-git/
 
helps. If you have further questions, it's probably easier if ask can ask 
in #django-dev on IRC rather the on this mailing list (which reaches 
hundreds of people). Thanks!

On Tuesday, September 22, 2015 at 9:32:06 AM UTC-4, Anjul Tyagi(geety) 
wrote:
>
> How do I represent the changes the I made in the documentation, I created a 
> branch of the ticket on my local django repository but now should I create a 
> .txt file with the changes or create two new .txt files, one representing the 
> original documentation and other representing the edited version and then 
> share the "diff" file of the two ?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/c0c0a182-8845-4839-ba32-a1f89764acfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Michael Manfre]

I'm -1 on having a default max_length on CharField. We should encourage
developers to be more explicit when defining their models, not less. I've
inherited way too many databases that suffered from "VARCHAR(255)" being
chosen as the arbitrary "any field storing even a few characters will be
this length".

Instead of adding a default (and encouraging bad database schemas), what
are thoughts about adding a helper function to allow people to define their
own new CharField as a one liner? E.g. ShortCharField =
make_max_length_char_field(255)

I agree that the Postgresql specific field should exist in
django.contrib.postgres.

Regards,
Michael Manfre

On Tue, Sep 22, 2015 at 8:40 AM, Collin Anderson 
wrote:

> If anyone's curious, the mysql situation is as crazy as you might expect.
> :)
>
> The max is only determined only by the total row size (65,535 bytes) and
> the index size (767 bytes default).
>
> Mysql defaults to only allowing 3-byte (no emoji) unicode characters, so
> 65,535/3=21,845 max across the entire row (the sum of all of the maxes of
> all char/varchar columns), and each indexed field only gets 767/3=255
> characters by default.
>
> If you change to 4-byte unicode characters, (which you should, but django
> doesn't really help you out #18392), your max_lengths can add up to
> 65,535/4=16,383 characters, and if you want the field to be indexed, you
> only get 191 characters (using the default index size). It's possible to
> only index the first 767/4=191 characters of the field, but django doesn't
> really support that.
>
> Basically, 255 works pretty well by default, allowing 65,535/3/255=85
> 3-byte fields per row, and indexes just work if you stick to the default
> settings.
>
> https://dev.mysql.com/doc/refman/5.0/en/char.html
> https://code.djangoproject.com/ticket/18392
>
>
> On Tue, Sep 22, 2015 at 1:56 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hi Shai,
>>
>> On 22 sept. 2015, at 04:22, Shai Berger  wrote:
>>
>> > I'd solve the "need to specify" issue by setting a default that is
>> > intentionally smaller than the smallest (core) backend limitation, say
>> 128.
>>
>> I would pick the highest value supported by all core backends (probably
>> 255
>> for MySQL, unless there’s something about indexes and multi-byte encodings
>> that I forget) in order to minimize the need to increase it.
>>
>> If we go for a lower value, I suggest to pick something totally arbitrary
>> like
>> 100 to make it clear that it isn't a technical limitation.
>>
>> > I"d make an "unlimited length text field" a new type of field,
>> explicitly not
>> > supported on MySql and Oracle; and I'd suggest that it can live outside
>> core
>> > for a while. so we may get an impression of how popular it really is.
>>
>> The main use case seems to be “VARCHAR() on PostgreSQL”. What about
>> defining a
>> slight variant of CharField in django.contrib.postgres that merely makes
>> the
>> max_length argument default to None?
>>
>> --
>> Aymeric.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers  (Contributions to Django itself)" 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/17C37814-E6A8-4E27-B590-BF9FFF42CB20%40polytechnique.org
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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/CAFO84S5TUwLPf%3DRrGXL4%3Dvf3647CufOsijiznttVQF%2BxYHaBFg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 

Re: Making max_length argument optional

['Tom Evans' via Django developers (Contributions to Django itself)]

On Tue, Sep 22, 2015 at 1:49 AM, Podrigal, Aron
 wrote:
> Different schemas?? Schema will always be different for each database
> backend according to its datatypes. I really don't understand what your
> concern is. In any case your free to specify a max_length=N where it will be
> the same for all backends.

This change would allow a django site running on postgres that you
could not dump the data from and reimport in to mysql without data
loss. It would make it easy to write non-portable apps without
thinking.

>
> While this makes sense, the use of TextField is also for the purpose of
> having rendered a text widget for ModelForms. So we should allow a
> max_length of None for both.
>

(I'm replying to two emails from you in one, hope that is alright)

No, TextField is used to designate an arbitrary length text field.
Having a widget.Textarea as the default input for this field is just a
default, it is perfectly correct to override the defaults either for
CharField or TextField to provide the desired widget type.

One should not be using models.TextField because a widget.Textarea is
desired for forms, instead it is to tell the database backend that the
column for this field should be an arbitrary length text type.

If the problem that is to be solved is that there is no easy way to
specify an arbitrary length text field that uses an input, this can be
solved with a very simple class:

class TextFieldWithInput(models.TextField):
def formfield(self, **kwargs):
defaults = {'widget': forms.TextInput}
defaults.update(kwargs)
return super(TextfieldWithInput, self).formfield(**defaults)

The main argument seems to be "Its a pain to think about the size of
my data when defining my database tables"; if we aren't thinking about
it then, then when do we think about it? Its kind of important..

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAFHbX1LbVfR4LdaqfF2S266dxhYRKA5B_dvbBA17c720spJKeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Alexey Zankevich]

Hi Josh,

As https://github.com/django/django/pull/5090 pull request merged into 
master, I wanted to extend django-orm-sugar library with some 
functionality, related to passing transforms or lookup objects. Currently 
it's not clear to me how lookups or transforms can be used in that way.
I'm talking about mentioned earlier syntax:

GameSession.objects.filter(GreaterThan('user__profile__last_login_date', 
> yesterday))
>

Could you give me a starter point for that?

Thanks,
Alexey


On Wednesday, August 26, 2015 at 6:04:02 PM UTC+3, Alexey Zankevich wrote:
>
> The patch allowing F objects for select_related and prefetch_related 
> methods was trivial, unfortunately F uses "name" field as a part of 
> Expression interface, so dotted querying will conflict with internal field 
> (as "name" is quite a popular name for model field).
>
> >>> Contains(F.user.name, "Bob")   # conflict
> Will work on another patch with custom class.
>
>
> On Tuesday, August 25, 2015 at 1:12:56 PM UTC+3, Alexey Zankevich wrote:
>
> Gotcha.
> So, F objects seem to be pretty good as generic interface to specify query 
> paths, the only remaining patch - adding select_related and 
> prefetch_related support. I'll preapare a preliminary pull request soon.
>
>
> On Tuesday, August 25, 2015 at 2:48:10 AM UTC+3, Josh Smeaton wrote:
>
> Expressions have built in support for ordering with asc or desc, see here: 
> https://docs.djangoproject.com/en/1.8/ref/models/expressions/#django.db.models.Expression.asc
>
> Meaning that -F() is never ambiguous, which is the main reason we went for 
> the F().desc() API rather than using the minus sign as an indicator of 
> ordering.
>
> To use the `P` example in an order by statement:
>
> Model.objects.order_by(P.related.date_field().desc())
>
> I've "called" date_field here, but that's just assuming an API. As long as 
> an expression is being returned, you can call `desc` on it.
>
> What some other ORMs do is reference fields directly on the model, though 
> I'm not sure I like the verboseness (but it gives you safety):
>
> Model.objects.order_by(Model.related.date_field.desc())
>
> The extra `Model` is annoying, but it does mean that you can actually look 
> up fields as you go rather than just crafting an `F()` that is eventually 
> resolved into the `Col()`. This would also allow us to return expressions 
> directly. Not sure how or if this API would work with the current 
> metaclasses though.
>
> For what it's worth, the names `TreePath` and `FieldTree` are too low 
> level for a public facing API that is supposed to make it easier/safer to 
> craft field paths. One letter class names are also a bad design in general, 
> so we'd need something half way between both if going for a new class.
>
>
> On Tuesday, 25 August 2015 04:13:32 UTC+10, Alexey Zankevich wrote:
>
> Hey Josh,
>
> Here is the current state of F support by different functions:
>
> * annotations (Count, Sum etc) - work
> * order_by - works partially (only asc order supported)
> * select_related, prefetch_related - don't work
>
> So, F is not a universal interface for getting paths right now. Also, 
> there is another problem with F - it overloads python operators already, so 
> if we overload unary operation "-F", it will confuse users as in one case 
> it will return CombinedExpression (ex. 0-F('fieldname')), in the other - 
> OrderBy (ex. -F('fieldname')).
> Since F originally designed to describe arithmetic upon fields during 
> filtering, it will not be a perfect match to denote query paths.
> As for accepting callable as a query path factory, I don't think it's a 
> perfect match as well, as callable interface is too general, at least to be 
> an unnamed argument.
> For example, fields.CharField(default=callable) is a clear approach, as 
> it's obvious what was implied. 
> ModelClass.objects.all().order_by(callable) - still clear, but 
> YearGte(callable, 40) isn't (since I'm talking about general interface to 
> specify query paths in the whole project).
> So, I suggest a separate class for that purposes, and it doesn't 
> necessarily need to have short name like "P". Even better if it has 
> meaningful name like "TreePath" or "FieldTree".
>
>
> On Friday, August 21, 2015 at 4:26:34 AM UTC+3, Josh Smeaton wrote:
>
> Most expressions already support strings, and most that support strings 
> expect them to be field_paths that can be wrapped in F() expressions. So 
> you have two options really, without built in support from other 
> expressions.
>
> 1. P.field.other.some_field() returns an F()
> 2. P.field.other.some_field() returns a str that will be internally 
> wrapped in an F().
>
> The callable part of your syntax is just something I'm suggesting as an 
> option. The requirement is that a string or F() be returned in some way 
> though. I'm also using "P." as a stand-in as you used previously.
>
> Supporting callables is an interesting idea, and I don't think that'll 
> cause issues with existing expressions. The 

moving the class-based View base class out of django.views.generic?

[Tim Graham]

Class-based view users, does this proposal from 
https://code.djangoproject.com/ticket/25385 seem like a good one?

---

Whenever I talk about class-based views and how their concept is separate 
from generic views (typically in a class setting), the question I am asked 
is invariably: if they are different, why do we import View from 
django.views.generic?

To help developers better avoid confusion and better separate the concepts, 
I would like to change the import of the View class. Ideally:

from django.views import View

I would furthermore like to move View from the generic directory into it's 
own module.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/ffad765a-0803-47c1-8bd0-9bd69fff0835%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: moving the class-based View base class out of django.views.generic?

[John Paulett]

Definitely seems like a good idea to me.  Even as a frequent CBV user, it
always takes me a few seconds to remember to import from generic.

John Paulett

On Tue, Sep 22, 2015 at 10:41 AM, Tim Graham  wrote:

> Class-based view users, does this proposal from
> https://code.djangoproject.com/ticket/25385 seem like a good one?
>
> ---
>
> Whenever I talk about class-based views and how their concept is separate
> from generic views (typically in a class setting), the question I am asked
> is invariably: if they are different, why do we import View from
> django.views.generic?
>
> To help developers better avoid confusion and better separate the
> concepts, I would like to change the import of the View class. Ideally:
>
> from django.views import View
>
> I would furthermore like to move View from the generic directory into
> it's own module.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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/ffad765a-0803-47c1-8bd0-9bd69fff0835%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CANRBGvbcHky7ipVjAV40xJrLZCbUW0UfB8L4agn8rvm4q22CRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: moving the class-based View base class out of django.views.generic?

[Tom Christie]

Yup, I think that's a good proposal.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/61cbcc8c-08d9-42af-83d5-4a8ee3d79dac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: moving the class-based View base class out of django.views.generic?

[Marc Tamlyn]

The idea has been discussed before and was rejected as needless code churn
if I remember correctly. I'm afraid I can't remember when or where this
discussion happened, it could have been an in person one at a sprint, I
can't immediately find a record on this mailing list. Perhaps the fact it's
come up again makes it more significant (and we can always keep the import
shim).

FWIW, I am +0, I can see the reasoning but in my opinion we have worse
import paths (conf.urls and core.urlresolvers anyone?)



On 22 September 2015 at 15:58, Tom Christie  wrote:

> Yup, I think that's a good proposal.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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/61cbcc8c-08d9-42af-83d5-4a8ee3d79dac%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAMwjO1ERvJxM1Zj%3DpOJRTX4zY3dqWg_PBYQ-5vQCPCuP-9i8iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.9 release blockers

[Tim Graham]

The second patch has been committed, and the first one is still under 
review. 

Florian says "with all that forth and back [on the pull request] I am not 
sure if it is not better to defer it to 1.10, i.e. I completely missed the 
base64 stuff for instance. One option would be to ship it with the feature 
inactive and mark it as experimental and ask users to try it out. Though, 
that would probably be a first."

I'd also be more comfortable if it were disabled by default. The main 
problem for me is the documentation doesn't really motivate the feature 
very well and describe how one should go about setting the values of the 
new settings.

Options:
1) Defer the patch to 1.10 and release the alpha today.
2) Maintain the feature freeze until the end of the week to see if the 
patch is better resolved by then (fix bugs on master in the meantime) and 
release the alpha then (whether or not the patch is completed).
3) Create the 1.9 branch today to allow normal development to proceed on 
master and release the alpha by the end of the week with the option to 
backport the patch if it's completed.

Opinions?

On Monday, September 21, 2015 at 9:08:22 PM UTC-4, Tim Graham wrote:
>
> Let's consider master feature frozen for now. There are two more patches 
> I'd like to merge before we cut the 1.9 branch.
>
> #21231 -- Enforced a max size for POST values read into memory
> https://github.com/django/django/pull/3852
> Status: Needs final code reviews and probably some doc enhancements (docs 
> could possibly be deferred until after alpha). Florian & Shai, as you've 
> been taking the lead on reviewing this, please let us know your thoughts.
>
> #24509 -- Added Expression support to SQLInsertCompiler
> https://github.com/django/django/pull/5324 
> Status: Josh working on some doc enhancements now, I will review in the 
> morning.
>
> On Friday, September 18, 2015 at 10:03:45 AM UTC-4, Marc Tamlyn wrote:
>>
>> Sorry everyone :(
>>
>> On 18 September 2015 at 15:01, Tim Graham  wrote:
>>
>>> The major features are officially deferred. Let's try for the feature 
>>> freeze by end of day on Monday and the alpha release on Tuesday.
>>>
>>> There aren't any critical blockers at this time. Jani hasn't completed 
>>> the Oracle GIS work, but this isn't a must-have for alpha.
>>>
>>>
>>> On Saturday, September 12, 2015 at 7:50:31 PM UTC-4, Tim Graham wrote:

 With 1 week to go until alpha:

 I haven't heard anything from Marc or Preston on the major features 
 from the last mail.

 Jani continues to give updates in #django-dev about his progress on 
 getting the Oracle GIS backend working. Things seem to be on track for 
 finishing up by alpha.

 On Friday, September 4, 2015 at 3:55:22 PM UTC-4, Tim Graham wrote:
>
> Status with 2 weeks and a weekend to go until alpha (Monday, September 
> 21).
>
> Planned major features for 1.9:
>
> PostgreSQL Full Text Search (Marc Tamlyn)
>
> I haven't seen any recent activity on the pull request, nor have I 
> heard anything from Marc about it.
> https://github.com/django/django/pull/4726
>
> Custom indexes (Marc Tamlyn)
>
> I haven't see any work on revising the DEP, so this seem out for 1.9.
>
> https://github.com/django/deps/pull/6
>
> Template-based widget rendering (Preston Timmons)
> I think the code is in fairly good shape. It seems the main work left 
> to is to write documentation.
> https://github.com/django/django/pull/4848
>
> Release blockers:
>
> - Add Oracle support for new-style GIS functions
> https://code.djangoproject.com/ticket/24688
> Owner: Jani Tiainen
> Status: In progress (from recent IRC discussion, it sounds like Jani 
> is making good progress)
>
> On Monday, August 24, 2015 at 3:40:22 PM UTC-4, Tim Graham wrote:
>>
>> Time to kickoff the progress tracker for the next major release!
>>
>> Here's the status with 4 weeks to go until alpha (September 21).
>>
>> Release blockers:
>>
>> - Add Oracle support for new-style GIS functions
>> https://code.djangoproject.com/ticket/24688
>> Owner: Jani Tiainen
>> Status: In progress (test suite runs on Oracle now, which is an 
>> improvement from last week)
>>
>>
>> Other tickets tagged for 1.9:
>>
>> - No way to create tables for apps without migrations
>> https://code.djangoproject.com/ticket/25144
>> Status: Awaiting replies to "Keeping apps without migrations?" thread 
>> for a decision on what to do
>> Mailing list thread: 
>> https://groups.google.com/d/topic/django-developers/qHP4ZQSK9xM/discussion
>> Owner: pending discussion
>>
>> - Replace admin icons images by inline SVG
>> https://code.djangoproject.com/ticket/20597
>> Owner: elky
>> Status: In progress
>>
>> - Update tutorial screenshots for new admin 

Re: moving the class-based View base class out of django.views.generic?

[Collin Anderson]

Could we have permanent backward-compatible (no deprecation timeline)
shims? I'm -0 if not because it's yet-another thing that everyone needs to
change when upgrading.

On Tue, Sep 22, 2015 at 11:23 AM, Marc Tamlyn  wrote:

> The idea has been discussed before and was rejected as needless code churn
> if I remember correctly. I'm afraid I can't remember when or where this
> discussion happened, it could have been an in person one at a sprint, I
> can't immediately find a record on this mailing list. Perhaps the fact it's
> come up again makes it more significant (and we can always keep the import
> shim).
>
> FWIW, I am +0, I can see the reasoning but in my opinion we have worse
> import paths (conf.urls and core.urlresolvers anyone?)
>
>
>
> On 22 September 2015 at 15:58, Tom Christie 
> wrote:
>
>> Yup, I think that's a good proposal.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" 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/61cbcc8c-08d9-42af-83d5-4a8ee3d79dac%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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/CAMwjO1ERvJxM1Zj%3DpOJRTX4zY3dqWg_PBYQ-5vQCPCuP-9i8iw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAFO84S41FtSqK0qNyLj1iNwc01nUQ%2BQiNps2S1%3Di516AtS5jzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Christophe Pettus]

On Sep 22, 2015, at 1:01 AM, Remco Gerlich  wrote:

> Maybe django.contrib.postgres could have a ArbitraryLengthCharField?

Just a note that, on PostgreSQL, that's exactly what TextField is.  There might 
be a use for a field that creates a VARCHAR without length on PostgreSQL, but I 
can't think of it.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/D6E9D391-883D-4CB7-B9E2-78D6ACB8F7A4%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

As I understand it, the problem with increasing the number of iterations on 
the slower hasher is that upgrading Django could effectively result in a 
DDoS attack after you upgrade Django as users passwords are upgraded.

Some benchmarking suggests that the new algorithm results in a 3x speed up 
(100,000 iterations done 100 times is ~30 sec. on old Python 2.7's and ~10s 
with 2.7.8+).

An option could be to make the number of iterations dependent on the Python 
version?

On Tuesday, September 22, 2015 at 12:15:46 AM UTC-4, Josh Smeaton wrote:
>
> Is the concern that 100,000 iterations is too slow on python < 2.7.8 but 
> is acceptable on versions after that? If so, then we wouldn't be breaking < 
> 2.7.8, we'd just be reducing the performance profile, right? We could call 
> out such things in the release notes. 
>
> On Tuesday, 22 September 2015 02:12:35 UTC+10, Donald Stufft wrote:
>>
>> On September 21, 2015 at 10:55:57 AM, Collin Anderson (cmawe...@gmail.com) 
>> wrote: 
>> > Is there an external library for Python < 2.7.8? I know we don't 
>> officially 
>> > support the system version of python in RHEL/CentOS and Ubuntu, but I 
>> bet 
>> > we could get away with requiring a dependency for those old versions of 
>> > Python in new versions of Django. 
>> >   
>>
>>
>>
>> https://cryptography.io/en/latest/hazmat/primitives/key-derivation-functions/#cryptography.hazmat.primitives.kdf.pbkdf2.PBKDF2HMAC
>>   
>>
>>
>> - 
>> Donald Stufft 
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
>> DCFA 
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/f6185ad5-d3ce-44d9-bef4-b8749db24df5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Christophe Pettus]

On Sep 22, 2015, at 10:18 AM, Tim Graham  wrote:

> As I understand it, the problem with increasing the number of iterations on 
> the slower hasher is that upgrading Django could effectively result in a DDoS 
> attack after you upgrade Django as users passwords are upgraded.

Is that correct?  My understanding was that the passwords were only modified 
when changed.  Given that it is a unidirectional hash, I'm not sure how they 
*would* be rehashed.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/07FDF35A-5495-4BFE-A4CE-BD976537B5B0%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

We have access to the plain text password when the user logs in.

On Tuesday, September 22, 2015 at 1:23:01 PM UTC-4, Xof wrote:
>
>
> On Sep 22, 2015, at 10:18 AM, Tim Graham  
> wrote: 
>
> > As I understand it, the problem with increasing the number of iterations 
> on the slower hasher is that upgrading Django could effectively result in a 
> DDoS attack after you upgrade Django as users passwords are upgraded. 
>
> Is that correct?  My understanding was that the passwords were only 
> modified when changed.  Given that it is a unidirectional hash, I'm not 
> sure how they *would* be rehashed. 
>
> -- 
> -- Christophe Pettus 
>x...@thebuild.com  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/ede8e9f2-cd9f-4d4f-aad6-36f52893957d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Christophe Pettus]

On Sep 22, 2015, at 10:27 AM, Tim Graham  wrote:

> We have access to the plain text password when the user logs in.

Right, so we could *in theory* upgrade the user's password then if we wished 
(not clear if we want to).  Even so, I don't think that would be a DDoS-attack 
level problem, since it's no worse than a user resetting their password.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/1D76A603-9715-422C-8E2D-42281721E229%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

Sorry, I explained poorly. We do upgrade passwords when the iteration count 
is increased 
https://docs.djangoproject.com/en/1.8/topics/auth/passwords/#password-upgrading

If we increase the iterations to , when a user logs in, we 
have to hash  to check the password against the current 
hash plus  to store the upgraded password. If pbkdf2 is 
slow, isn't it reasonable that this could cause a CPU spike on a high 
traffic site?

On Tuesday, September 22, 2015 at 1:39:12 PM UTC-4, Xof wrote:
>
>
> On Sep 22, 2015, at 10:27 AM, Tim Graham  
> wrote: 
>
> > We have access to the plain text password when the user logs in. 
>
> Right, so we could *in theory* upgrade the user's password then if we 
> wished (not clear if we want to).  Even so, I don't think that would be a 
> DDoS-attack level problem, since it's no worse than a user resetting their 
> password. 
>
> -- 
> -- Christophe Pettus 
>x...@thebuild.com  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/bd8df6d7-4355-427e-83b4-024482e2fdf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANNOTATIONS WORKING

[varun naganathan]

https://code.djangoproject.com/ticket/25316


On Tuesday, September 22, 2015 at 6:13:33 PM UTC+5:30, Tim Graham wrote:
>
> What's the ticket number?
>
> On Tuesday, September 22, 2015 at 7:56:04 AM UTC-4, varun naganathan wrote:
>>
>> The bug is already reported and the triage stage is accepted.I'm in the 
>> path of trying to fix the bug so kind if needed guidance on how to pursue 
>> solving it . 
>> Thanks 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/39b7fdfc-5a19-45cc-adf3-68727ed25698%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Alex Gaynor]

Sure, but such a problem has nothing to do with password upgrades, it can
already be triggered by registration, or even just logging in without a
password upgrade.

Alex

On Tue, Sep 22, 2015 at 2:43 PM, Tim Graham  wrote:

> Sorry, I explained poorly. We do upgrade passwords when the iteration
> count is increased
> https://docs.djangoproject.com/en/1.8/topics/auth/passwords/#password-upgrading
>
> If we increase the iterations to , when a user logs in, we
> have to hash  to check the password against the current
> hash plus  to store the upgraded password. If pbkdf2 is
> slow, isn't it reasonable that this could cause a CPU spike on a high
> traffic site?
>
> On Tuesday, September 22, 2015 at 1:39:12 PM UTC-4, Xof wrote:
>>
>>
>> On Sep 22, 2015, at 10:27 AM, Tim Graham  wrote:
>>
>> > We have access to the plain text password when the user logs in.
>>
>> Right, so we could *in theory* upgrade the user's password then if we
>> wished (not clear if we want to).  Even so, I don't think that would be a
>> DDoS-attack level problem, since it's no worse than a user resetting their
>> password.
>>
>> --
>> -- Christophe Pettus
>>x...@thebuild.com
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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/bd8df6d7-4355-427e-83b4-024482e2fdf0%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAFRnB2V53_3KBHWKiYLq_i1c1UGdCLtOgYZSrFviO5i9FeDQHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

Right -- the performance is only slightly worse during an upgrade than 
during other actions. I found the conversation I was thinking about. It's 
in the private security tracker (the patch to upgrade the iterations count 
was developed there), so I'll copy/paste the relevant bits here. The patch 
in question is 
https://github.com/django/django-private/commit/7d0d0dbf26a3c0d16e9c2b930fd6d7b89f215946

Paul McMillan: "I don't believe this is necessary"

Donald Stufft: @PaulMcMillan Why? I think it's a good change and I think 
it's needed. Otherwise in X years people created with a 1.4 era hasher will 
have severely weaker password hashes.

P: "Upgrading hashes like the patch does causes double the login load after 
any upgrade. The hashing margin is already high, and having "my server's 
running really slow and everything broke after I upgraded" is not a good 
deployment experience. It will also cause people to say "hmm, maybe these 
new hashes are too many rounds, let's switch to something less secure". 

@dstufft "severely weaker" is an overstatement.

Any security change which dramatically changes the load on a server is 
something we have to weigh extremely carefully. I don't think this is an 
acceptable tradeoff. The design goal was to have hashes gradually get 
upgraded as users create new passwords or change existing ones. This allows 
admins to see the load increasing gradually, and plan server resources 
accordingly. Walloping them with a wall of increased load immediately after 
upgrade isn't fair, and discourages users from upgrading."

D: "@PaulMcMillan I don't believe I agree with that. Using PBKDF2 is 
already a fraction of what you get with bcrypt so by that logic we 
shouldn't allow any use of bcrypt either. Notably passlib supports this 
upgrading of hash iterations (although they have a range of acceptable 
values).

Severely weaker isn't an understatement. It takes 5 releases past whichever 
release increases the limit to 12000 to get roughly double the iterations 
from the 1.4 number of 10k. As far as I know Django is planning on a 6month 
release schedule so that means 2 and a half years any user who was created 
with a 1.4, 1.5, 1.6 installation has a password hash half as strong as one 
created in 2 years. There's no way for that user to *get* a stronger hash 
besides change their password which most users do not do unless forced to.

P: "`` ok then.

As I've said before, anyone using this in large scale production is 
probably using weaker hashers anyway.

It's really a nasty surprise to have user logins take more than twice as 
much cpu when you bring the site back from any major upgrade, but I guess 
most people won't even notice that, since they aren't running at scale.

Too bad this isn't the sort of behavior a large deployment is likely to 
notice during pre-upgrade testing before it bites them in the ass during a 
real upgrade with users hammering the server trying to get back in after 
planned downtime."
--

At this point, I'm inclined to continue with the 20-25% iterations increase 
per release methodology we've been using unless someone wants to advocate 
for one of the other proposals. We only have 2 releases left (1.10 and 
1.11) that will support Python 2. After dropping Python 2 and any chance 
that someone will be using the slower pbkdf2, we can reevaluate.

On Tuesday, September 22, 2015 at 2:59:18 PM UTC-4, Alex_Gaynor wrote:
>
> Sure, but such a problem has nothing to do with password upgrades, it can 
> already be triggered by registration, or even just logging in without a 
> password upgrade.
>
> Alex
>
> On Tue, Sep 22, 2015 at 2:43 PM, Tim Graham  > wrote:
>
>> Sorry, I explained poorly. We do upgrade passwords when the iteration 
>> count is increased 
>> https://docs.djangoproject.com/en/1.8/topics/auth/passwords/#password-upgrading
>>
>> If we increase the iterations to , when a user logs in, 
>> we have to hash  to check the password against the 
>> current hash plus  to store the upgraded password. If 
>> pbkdf2 is slow, isn't it reasonable that this could cause a CPU spike on a 
>> high traffic site?
>>
>> On Tuesday, September 22, 2015 at 1:39:12 PM UTC-4, Xof wrote:
>>>
>>>
>>> On Sep 22, 2015, at 10:27 AM, Tim Graham  wrote: 
>>>
>>> > We have access to the plain text password when the user logs in. 
>>>
>>> Right, so we could *in theory* upgrade the user's password then if we 
>>> wished (not clear if we want to).  Even so, I don't think that would be a 
>>> DDoS-attack level problem, since it's no worse than a user resetting their 
>>> password. 
>>>
>>> -- 
>>> -- Christophe Pettus 
>>>x...@thebuild.com 
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To 

Re: Methodology for increasing the number of PBKDF2 iterations

[Aymeric Augustin]

> On 22 sept. 2015, at 19:22, Christophe Pettus  wrote:
> 
> Given that it is a unidirectional hash, I'm not sure how they *would* be 
> rehashed.

If you have password hashed at 15 000 rounds and want 20 000, you do 5 000 
rounds on the current hash. (I don’t know if Django does this.)

-- 
Aymeric.




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/EA8B3AD6-B26A-4B7B-8922-85D9DA585F40%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Aymeric Augustin]

On 22 sept. 2015, at 21:21, Tim Graham  wrote:

> At this point, I'm inclined to continue with the 20-25% iterations increase 
> per release methodology we've been using unless someone wants to advocate for 
> one of the other proposals.


I agree.

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/C0919935-7FA2-40E6-9D93-AF61F4FC6C5C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: moving the class-based View base class out of django.views.generic?

[Josh Smeaton]

>
> Could we have permanent backward-compatible (no deprecation timeline) 
> shims? I'm -0 if not because it's yet-another thing that everyone needs to 
> change when upgrading.
>
> +1 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/d5d22b50-c8c8-4c64-ac2b-a4603e7dbbed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: moving the class-based View base class out of django.views.generic?

[Russell Keith-Magee]

On Wed, Sep 23, 2015 at 7:06 AM, Josh Smeaton  wrote:
>> Could we have permanent backward-compatible (no deprecation timeline)
>> shims? I'm -0 if not because it's yet-another thing that everyone needs to
>> change when upgrading.
>>
> +1

That would be my preferred approach, too.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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_c0qKttEXxqxCKq4iD210JSSaCshQtq_0G7BkD%2BYxD2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.9 release blockers

[Russell Keith-Magee]

On Wed, Sep 23, 2015 at 12:54 AM, Tim Graham  wrote:
> The second patch has been committed, and the first one is still under
> review.
>
> Florian says "with all that forth and back [on the pull request] I am not
> sure if it is not better to defer it to 1.10, i.e. I completely missed the
> base64 stuff for instance. One option would be to ship it with the feature
> inactive and mark it as experimental and ask users to try it out. Though,
> that would probably be a first."
>
> I'd also be more comfortable if it were disabled by default. The main
> problem for me is the documentation doesn't really motivate the feature very
> well and describe how one should go about setting the values of the new
> settings.
>
> Options:
> 1) Defer the patch to 1.10 and release the alpha today.
> 2) Maintain the feature freeze until the end of the week to see if the patch
> is better resolved by then (fix bugs on master in the meantime) and release
> the alpha then (whether or not the patch is completed).
> 3) Create the 1.9 branch today to allow normal development to proceed on
> master and release the alpha by the end of the week with the option to
> backport the patch if it's completed.
>
> Opinions?

For me, it depends on how close Florian et al think the patch is. If
it's "close, but a few things need to be tweaked", then option 2 or 3
sounds good to me. A couple of days won't make much difference in the
overall schedule, so whichever is easier for Tim to manage works for
me. If it's "oh no, we missed this major use case", then option 1 is
probably where we are.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAJxq849s8jaiGFsXDnwwRtdb-t4SRoWHMyVwrAsVkgKCpv3a_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.