Make DATABASES[x]['TEST']['USER'], etc available for non-Oracle DBs

[matt]

Currently, the TEST database settings like USER and PASSWORD are only used 
by the Oracle backend. 

See: 
https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TEST_USER

I just hit a case where it would be nice to use a different database user 
during testing -- and I don't use Oracle. I know there are workarounds, but 
since Django already provides an elegant way to solve the problem (for one 
backend), why not do it for the others?

I'd be happy to contribute a patch, but I'm curious if that feature was 
left out of the other backends for a reason.

-- 
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/498eb856-4732-4d10-aa79-01800fa6d461%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make DATABASES[x]['TEST']['USER'], etc available for non-Oracle DBs

[Shai Berger]

On Monday 21 September 2015 00:46:51 m...@satchamo.com wrote:
> Currently, the TEST database settings like USER and PASSWORD are only used
> by the Oracle backend.
> 
> See:
> https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TEST_USER
> 
> I just hit a case where it would be nice to use a different database user
> during testing -- and I don't use Oracle. I know there are workarounds, but
> since Django already provides an elegant way to solve the problem (for one
> backend), why not do it for the others?
> 

I would agree, except that the role played by the test user on Oracle is 
different from that which would be played on e.g. PostgreSQL.

Oracle has no concept of separate databases owned by a single user like other 
DBMSs do. Thus, in order to have a throw-away schema for testing, there is no 
choice but to create a user. I suspect on your other backend, the reason to 
use another username for testing is quite different. and the user would not be 
created as part of the test setup.

The Oracle backend allows you to also use a pre-existing user for testing, but 
the purpose there is basically the same as the --keepdb flag (the relevant 
Oracle settings predate --keepdb).

I think there are Oracle-only TEST settings which would make sense for other 
backends -- CREATE_DB and TBLSPACE, mostly. Other than that, I suspect it may 
make sense to use a different host/port for testing -- because for PostgreSQL, 
there are several speed-vs-integrity trade-offs that can only be made at the 
server level. and users' preferences on these trade-offs can differ very 
significantly between a throw-away test database and "production" -- even if 
"production" is really just a developer's database.

> I'd be happy to contribute a patch, but I'm curious if that feature was
> left out of the other backends for a reason.

AFAIK, it was the other way around: The feature was *added* for Oracle, and 
not others, because it was needed there.

HTH,
Shai.

Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

The latest guidance on increasing the number of PBKDF2 iterations for each 
release of Django was written by Alex in July 2014:

For each release... "Increase the default PBKDF2 iterations in 
django.contrib.auth.hashers.PBKDF2PasswordHasher by about 20% (pick a round 
number)."

He noted in that commit message, "The rate at which we've increased this 
has not been keeping up with hardware (and software) improvements, and 
we're now considerably behind where we should be. The delta between our 
performance and an optimized implementation's performance prevents us from 
improving that further, but hopefully once Python 2.7.8 and 3.4+ get into 
more hands we can more aggressively increase this number."

https://github.com/django/django/commit/6732566967888f2c12efee1146940c85c0154e60

Upon seeing a proposed 25% increase for 1.10 (to bring the iteration count 
to 30,000), Claude and Aymeric questioned this:

Aymeric: "I don't believe single-threaded execution gets 25% faster every 8 
months with modern CPUs. Should be have a guideline about the duration of 
one call to the hasher on some reference platform?
Claude: "Same question for me. I wouldn't blindly apply that 25% increase 
each time. It's good that we question that number at each release, but 
let's be smart enough to evaluate if the increase is justified or not."

-- 
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/a13898dc-5f34-4d3a-83f4-88dff82bdfb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Alex Gaynor]

Unfortunately here is where we hit an asymmetry: single threaded
performance of PBKDF2 _as realized in our pure Python implementation_
indeed does not improve by 25% every 8 months.

Unfortunately 24k iterations is behind where we'd want to be (~100k
iterations, or a factor of 4, last I checked).

The only way to reconcile this is for more users to get Python 2.7.8 and
3.4+, where there's a faster implementation of PBKDF2, or to entirely
switch to alternate algorithms such as bcrypt.

Alex

On Sun, Sep 20, 2015 at 7:20 PM, Tim Graham  wrote:

> The latest guidance on increasing the number of PBKDF2 iterations for each
> release of Django was written by Alex in July 2014:
>
> For each release... "Increase the default PBKDF2 iterations in
> django.contrib.auth.hashers.PBKDF2PasswordHasher by about 20% (pick a
> round number)."
>
> He noted in that commit message, "The rate at which we've increased this
> has not been keeping up with hardware (and software) improvements, and
> we're now considerably behind where we should be. The delta between our
> performance and an optimized implementation's performance prevents us from
> improving that further, but hopefully once Python 2.7.8 and 3.4+ get into
> more hands we can more aggressively increase this number."
>
>
> https://github.com/django/django/commit/6732566967888f2c12efee1146940c85c0154e60
>
> Upon seeing a proposed 25% increase for 1.10 (to bring the iteration count
> to 30,000), Claude and Aymeric questioned this:
>
> Aymeric: "I don't believe single-threaded execution gets 25% faster every
> 8 months with modern CPUs. Should be have a guideline about the duration of
> one call to the hasher on some reference platform?
> Claude: "Same question for me. I wouldn't blindly apply that 25% increase
> each time. It's good that we question that number at each release, but
> let's be smart enough to evaluate if the increase is justified or not."
>
> --
> 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/a13898dc-5f34-4d3a-83f4-88dff82bdfb8%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/CAFRnB2ULkZ7qrPbOwc9OGQBdiC0B1Jjv0UExRSoWR-ohOE91GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Donald Stufft]

On September 20, 2015 at 7:26:09 PM, Alex Gaynor (alex.gay...@gmail.com) wrote:
> > Unfortunately 24k iterations is behind where we'd want to be 
> (~100k iterations, or a factor of 4, last I checked).

If I remember, a key thing was we wanted the PBKDF2 iterations to be much
higher than they were because they hadn't kept up with improvements (or
adjusted at all at) but we didn't want to just jump from some low amount (20k?)
straight to 100k in one release. The 25% number was, if I recall, an attempt
to move us to that point over time, so it was purposely chosen to be faster
than CPU increases because if it was equal to that we'd never catch up to where
we should be.

-
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/etPan.55ff4179.5b345c86.ead3%40Draupnir.home.
For more options, visit https://groups.google.com/d/optout.

Some love for admindocs

[Žan Anderle]

Hi folks!

I've been thinking about admindocs lately and that they would really 
deserve more attention than they currently get. It's a quite useful feature 
and I think a very underrated one.

They were initially there to provide documentation for 'front-end people', 
when working on templates. While this may still be useful, we've already 
discussed that nowadays it's more common to use admindocs as internal 
documentation for developers. I think I'd be great if this position was 
reaffirmed inside the Django project. Some of the ways we could do that:

1. Have that position more clearly stated in the documentation for admindocs
2. Mention admindocs in other parts of the Django documentation. For 
example, it seems that following FK relations is often a lot easier with 
admindocs. Maybe that should be mentioned somewhere?
3. Mention admindocs in the tutorial. Not sure about this one, since it 
could just add unnecessary weight. But it might also make life easier for 
some people.
4. Add some possible new features:

   - documenting management commands 
   - having some kind of README per app. Tim Baxter provided an 
example/possible 
   implementation 
   

 
   of this on the irc channel. 

Anyway, I'd love to hear your thoughts.

Best,
Žan

-- 
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/3477f98f-7029-4a35-a3ef-ac41d2a9c8c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

Iv'e started to work on this ticket [1] today and here [2] is my work so
far. I'd appreciate some feedback on the implementation.
There are a couple ways to handle the database type length.

1) Separate types one with a length spec and one without (as mentioned
by Ben Davis in the ticket)
2) Some interface to get the type length specs (the approach I took)

The second option more generic, and provides an interface for any type to
specify a length or scale precision.

[1] https://code.djangoproject.com/ticket/14094
[2]
https://github.com/django/django/compare/master...ar45:max_length_optional

On Thu, Jul 30, 2015 at 5:15 AM, Aymeric Augustin <
aymeric.augustin.2...@polytechnique.org> wrote:

> > Le 29 juil. 2015 à 18:25, Podrigal, Aron  a
> écrit :
> >
> > I see models as what defines the database ddl and and not a
> representation from a  end users perspective.
>
> Django models do a bit more than this: see the `validators` argument,
> EmailField, etc.
> > And I see the tight coupling between the 2 improper.
>
> I understand your perspective; it's a trade-off between purity and
> convenience and the optimal answer depends on each project.
> > For me I rarely use the builtin generated widgets, I use restframework
> so all I'm interested in a model is for db definition in a highly
> customizable way.
>
> Please make sure your proposals also account for the various way Django
> can be and has been used :-)
>
> --
> 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/2A451482-2DDD-42CE-895B-55E1FF1026D3%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
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-yhpwRu2iwRU5TDf3NGbvVAYEnJPorjn3tAON0CHuTPEOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.