Re: Making max_length argument optional

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

Re: Making max_length argument optional

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. > >

Re: ANNOTATIONS WORKING

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

DJango 1.8 test case fails with IntegrityError error

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",

Re: Making max_length argument optional

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

Re: ANNOTATIONS WORKING

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

Re: Making max_length argument optional

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

Re: DJango 1.8 test case fails with IntegrityError error

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", >

Re: Making max_length argument optional

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

Re: ANNOTATIONS WORKING

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

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

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

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

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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

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

Re: Django ORM query syntax enhancement

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

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

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

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

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 >

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

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

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

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

Re: status of 1.9 release blockers

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

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

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

Re: Making max_length argument optional

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,

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: ANNOTATIONS WORKING

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

> 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

Re: Methodology for increasing the number of PBKDF2 iterations

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

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

> > 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

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

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

Re: status of 1.9 release blockers

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