Re: Trac #22343 -- select-for-update in autocommit mode

[Shai Berger]

On Monday 31 March 2014 09:18:57 Anssi Kääriäinen wrote:
> On 03/30/2014 07:48 PM, Shai Berger wrote:
> > While fixing this, I ran into this line in the current docs:
> > """
> > Using select_for_update on backends which do not support SELECT ... FOR
> > UPDATE (such as SQLite) will have no effect.
> > """
> > 
> > This raises two questions:
> > 
> > 1) This is a little inconsistent with the approach suggested above -- on
> > SQLite, we allow code that asks for locks to run without them. Should we
> > re- think one of these decisions? That is, should we let
> > select_for_update run with no effect when there is no transaction, or,
> > conversely, reject it entirely on SQLite?
> > 
> > My view is that for SQLite, the guarantees of data correctness are so low
> > anyway,  that we can allow this to pass, while on other backends the user
> > should expect better -- so, just do the change suggested above, in spite
> > of the apparent inconsistency.
> 
> On SQLite we could also ensure we have locked the database. On SQLite
> there can't be multiple writing transactions to the database, and if you
> do select_for_update you are certainly going to write to the db. So the
> right approach seems to be that the database is write locked already
> when we do the select. There is even a dedicated RESERVED lock type for
> this in SQLite. It seems the way to acquire RESERVED lock is to do a
> no-effect UPDATE, that is "UPDATE thetable set pk = 0 where 1 = 0"
> should give RESERVED lock to the database according to section 7.0 of
> SQLite's docs [https://www.sqlite.org/lockingv3.html].
> 
I've thought a lot about this -- I think the right approach is to add "support 
select-for-update on sqlite" as a new feature in 1.8, and with it the 
enforcement that select-for-update is not done in autocommit; but keep things 
as they are (on Sqlite, not generally) for older versions.

Arguments for other positions still welcome,

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/201404021218.09174.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Unicode in validators tests

[alois . guillope]

Hi,

I was wondering if the test inputs in the validators tests should be given 
as unicode or python string. It seems to me that at the moment the 
validation is done, the string is already coded in unicode. However the 
django tests use a python string as test input 
(https://github.com/django/django/blob/master/tests/validators/tests.py).

Could someone help me to clarify this? (chances are I don't dig encoding 
enough)

Thanks,

Alois

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/5ddac8da-e43b-41b0-818f-79b357258fb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

Well, having stayed up til 4AM on Monday night, I managed to get the whole 
book upgraded to Django 1.7, and published.  I've shared some thoughts on 
the migrations / tdd stuff we've been discussing, here:

http://www.obeythetestinggoat.com/book-upgraded-to-django-17.html

I'd be very interested in ppl's comments, particularly on the part of the 
book in which I introduce migrations:  am I saying the right things, am I 
giving people the right / best practice habits, etc.

http://chimera.labs.oreilly.com/books/123400754/ch05.html#_the_django_orm_amp_our_first_model

I think my overall conclusion is that the new migrations framework does 
involve a bit more pain, when doing tdd or when introducing newbies to 
django, but that that pain is worthwhile, since it's stuff that would come 
back and bite you later when you gloss over it (which you used to be able 
to do).

cheers all!
HP

On Tuesday, 1 April 2014 00:32:22 UTC+1, Andrew Godwin wrote:
>
> Yes, you can - the "migrations or not" switch is currently "is there a 
> migrations directory", but bear in mind this will eventually turn from "use 
> the old way" to "ignore it completely", probably also in 1.9.
>
> Andrew
>
>
> On Mon, Mar 31, 2014 at 4:15 PM, Harry Percival 
> 
> > wrote:
>
>> Just found out that you can make Django behave in the "old way" by just 
>> deleting the migrations folder when you first do your `startapp`, and then 
>> you can pretend migrations don't exist until you need them.  Don't think 
>> that's necessarily a good idea though...
>>
>>
>> On 30 March 2014 19:42, Andrew Godwin > >wrote:
>>
>>> You're roughly right, yes. String fields are a little odd, though, in 
>>> that you can have them blank=True without null=True and then the default 
>>> should be an empty string (Django's separation of blank and null irks me 
>>> still) - the migrations should correctly detect this and insert blank 
>>> strings for you then. If not, open a bug report!
>>>
>>> Andrew
>>>
>>>
>>> On Sun, Mar 30, 2014 at 5:13 AM, Shai Berger 
>>> 
>>> > wrote:
>>>
 On Sunday 30 March 2014 15:08:17 Harry Percival wrote:
 > Ah, so the reason I was confused is because it *looks* like the 
 default is
 > the empty string, because that's what you get if you initialise an 
 object,
 > by default. But at the database level, the default for the column is 
 NULL.
 > Is that right?
 >
 > So, I realise we're getting sidetracked here, but,  how does this fit 
 with
 > the fact that `null=False` is the default for all Field types?
 >

 Simply: The "default default" is that fields are required.

 But this is very deep in django-users territory.

 Shai.

 --

 You received this message because you are subscribed to the Google 
 Groups "Django developers" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to django-develop...@googlegroups.com .

 To post to this group, send email to 
 django-d...@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/201403301513.23581.shai%40platonix.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Django developers" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/django-developers/PWPj3etj3-U/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to 
>>> django-develop...@googlegroups.com .
>>>
>>> To post to this group, send email to 
>>> django-d...@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/CAFwN1urwhyZkfF9smfeeSOeS_8ejFdKmKo3X%3D4yfWd8DGU_%3DTA%40mail.gmail.com
>>> .
>>>  
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> --
>> Harry J.W. Percival
>> --
>> Twitter: @hjwp
>> Mobile:  +44 (0) 78877 02511
>> Skype: harry.percival 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/C

Re: Unicode in validators tests

[Shai Berger]

On Wednesday 02 April 2014 13:43:23 alois.guill...@gmail.com wrote:
> Hi,
> 
> I was wondering if the test inputs in the validators tests should be given
> as unicode or python string. It seems to me that at the moment the
> validation is done, the string is already coded in unicode. However the
> django tests use a python string as test input
> (https://github.com/django/django/blob/master/tests/validators/tests.py).
> 

They are "text" (=unicode) objects, not "bytes".

Notice line 2 in that file:

from __future__ import unicode_literals

You may want to look up the whole issue of strings, bytes and unicode in 
Python2 and Python3. 

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/201404021546.59709.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for prepared statements API

[Ramiro Morales]

On Thu, Mar 27, 2014 at 5:11 AM, VernonCole  wrote:
> There was a recent query about prepared statements on the db-sig mailing
> list, too. Apparently thought is being given to adding such functionality to
> Psycopg.

This thread on the psycopg mailing list (and the linked, older
discussion and article) of the status might be of interest regarding
the status of PS support in such DB-API driver:

http://www.postgresql.org/message-id/20140314184216.gb3...@fetter.org

-- 
Ramiro Morales
@ramiromorales

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

Re: Proposal: Database Constraints

[Anssi Kääriäinen]

On Wednesday, April 2, 2014 6:58:22 AM UTC+3, schinckel wrote:

> For that reason, I wouldn't be the fan of the exploded syntax you've 
>> given; I think I'd rather just be able to supply a list of strings for my 
>> constraints that are SQL themselves; there's no real benefit to abstraction 
>> here, and removing it doubtless removes a lot of code and bugs. Otherwise, 
>> I think I'd be +0.
>>
>
> Pushing on from there: it's not much work from doing "constraints = 
> ('check start < finish',)" to just writing a RunSQL migration operation. 
> The exploded syntax was more me working things through late at night 
> anyway. And it seems like there's not really much else to do other than raw 
> SQL for exclude constraints.
>
> So, it's actually possible to do _most_ of what I want already - just 
> using a migration. The per-field check constraint could/should also be 
> implemented as a validator. Exclude constraints are another kettle of fish: 
> as I mentioned before, it's not actually possible to validate these 
> constraints without hitting the database, and even then that's not alway 
> enough. You still need to handle IntegrityErrors if an update between when 
> you checked and when you actually try to save causes a conflict.
>

I'd concentrate effort on allowing fields to define arbitrary extra DDL for 
migrations. Other use cases for extra migrations for fields are custom 
index types and ability to do "CREATE EXTENSION some_extension" (for 
example hstore) when needed. Optimally the latter would be best done with a 
dependency to another migration so that CREATE EXTENSION will be ran only 
once, but doing CREATE EXTENSION IF NOT EXISTS is good enough.

The basic idea for this is to allow fields to give extra migration steps. 
Probably this is best done with get_extra_migrations() method that return a 
list of extra migration operations (instances of MigrationOperation class). 
I am not exactly sure how each migration operation should look like, but at 
the least it must be able to produce the needed SQL (per backend) for the 
step. Also, I don't know the migrations portion of the ORM that well, so it 
might be that a list of extra migration operation instances per field isn't 
sensible.

If get_extra_migrations() was available, then doing CHECK constraints and 
custom index definitions should be a lot easier. If one wants to write a 
field with EXCLUDE constraint in their project (or as 3rd party app) that 
should be possible, too.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/2c47e14e-3a46-49c0-8d08-e181f80dd058%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Database Constraints

[Andrew Godwin]

As I've said on other threads, fields can't define extra operations - they
must do everything inside the SchemaEditor's add_field method (operations
are not the only thing which calls the SchemaEditor, in theory). Ticket
#22022 (https://code.djangoproject.com/ticket/22022) covers this - there'll
be some kind of field method that SchemaEditor looks for for its extra SQL
to run.

I agree, though, Anssi - if we have that in there then it's a lot easier.

Andrew


On Wed, Apr 2, 2014 at 7:10 AM, Anssi Kääriäinen wrote:

> On Wednesday, April 2, 2014 6:58:22 AM UTC+3, schinckel wrote:
>
>> For that reason, I wouldn't be the fan of the exploded syntax you've
>>> given; I think I'd rather just be able to supply a list of strings for my
>>> constraints that are SQL themselves; there's no real benefit to abstraction
>>> here, and removing it doubtless removes a lot of code and bugs. Otherwise,
>>> I think I'd be +0.
>>>
>>
>> Pushing on from there: it's not much work from doing "constraints =
>> ('check start < finish',)" to just writing a RunSQL migration operation.
>> The exploded syntax was more me working things through late at night
>> anyway. And it seems like there's not really much else to do other than raw
>> SQL for exclude constraints.
>>
>> So, it's actually possible to do _most_ of what I want already - just
>> using a migration. The per-field check constraint could/should also be
>> implemented as a validator. Exclude constraints are another kettle of fish:
>> as I mentioned before, it's not actually possible to validate these
>> constraints without hitting the database, and even then that's not alway
>> enough. You still need to handle IntegrityErrors if an update between when
>> you checked and when you actually try to save causes a conflict.
>>
>
> I'd concentrate effort on allowing fields to define arbitrary extra DDL
> for migrations. Other use cases for extra migrations for fields are custom
> index types and ability to do "CREATE EXTENSION some_extension" (for
> example hstore) when needed. Optimally the latter would be best done with a
> dependency to another migration so that CREATE EXTENSION will be ran only
> once, but doing CREATE EXTENSION IF NOT EXISTS is good enough.
>
> The basic idea for this is to allow fields to give extra migration steps.
> Probably this is best done with get_extra_migrations() method that return a
> list of extra migration operations (instances of MigrationOperation class).
> I am not exactly sure how each migration operation should look like, but at
> the least it must be able to produce the needed SQL (per backend) for the
> step. Also, I don't know the migrations portion of the ORM that well, so it
> might be that a list of extra migration operation instances per field isn't
> sensible.
>
> If get_extra_migrations() was available, then doing CHECK constraints and
> custom index definitions should be a lot easier. If one wants to write a
> field with EXCLUDE constraint in their project (or as 3rd party app) that
> should be possible, too.
>
>  - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/2c47e14e-3a46-49c0-8d08-e181f80dd058%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" 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/CAFwN1uqifCrGKa0xnMAh_bxL%2B%2B5qahQOevwdYg%2B8ihJibCvXnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

On django multi tenancy

[Riccardo Magliocchetti]

Hi everyone,

i'd like to start a discussion about multi tenancy on this list. I've 
been asked to move the discussion here by Aymeric in this ticket:


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

First we already have an initial patch sitting in this ticket:

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

patch here:

https://code.djangoproject.com/attachment/ticket/15089/15089-missing-site_id.diff

The patch basically change the SiteManager to return a Site based on the 
request instead of the hardcoded settings.SITE_ID. Which while useful 
for my usage is also making ticket 17802 obsolete since in the mean time 
Sitemap has been switched to using get_current_site.


Another missing bit is having the request available everywhere, one 
solution is to store in thread local storage that could be done easily 
in a middleware without touching django core.


Another interesting thing (to me at least) would be being able to use a 
different model for the Site so one can stores some site specific 
configuration there (keeping in mind that in the patch sites return but 
get_current_site are cached).


That could be obtained through this patch:

https://github.com/apollo13/django/compare/ticket15089

or maybe like what is done for the custom User model.

There's some more features for full multi tenancy listed here
https://code.djangoproject.com/ticket/15089#comment:36

but the above will suffice for my usage so i will not dig into it.

So to summarize with just a couple of patches to the site framework and 
a dozen lines middleware one could build a basic django multi tenancy site.


How can I help to have this in 1.7?

thanks in advance,
riccardo

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

Re: On django multi tenancy

[Russell Keith-Magee]

On Thu, Apr 3, 2014 at 2:20 AM, Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:

> Hi everyone,
>
> i'd like to start a discussion about multi tenancy on this list. I've been
> asked to move the discussion here by Aymeric in this ticket:
>
> https://code.djangoproject.com/ticket/17802
>
> First we already have an initial patch sitting in this ticket:
>
> https://code.djangoproject.com/ticket/15089
>
> patch here:
>
> https://code.djangoproject.com/attachment/ticket/15089/
> 15089-missing-site_id.diff
>
> The patch basically change the SiteManager to return a Site based on the
> request instead of the hardcoded settings.SITE_ID. Which while useful for
> my usage is also making ticket 17802 obsolete since in the mean time
> Sitemap has been switched to using get_current_site.
>
> Another missing bit is having the request available everywhere, one
> solution is to store in thread local storage that could be done easily in a
> middleware without touching django core.
>

-1. Not. Going. To. Happen.

Search the archives of Django Developers if you want to know why. This has
been discussed to death.

Short version - it doesn't matter what pretty name you put on it, a thread
local is a global variable. We teach first year programmers not to use
globals, so why would we introduce them to Django as a core framework idea?


> Another interesting thing (to me at least) would be being able to use a
> different model for the Site so one can stores some site specific
> configuration there (keeping in mind that in the patch sites return but
> get_current_site are cached).
>
> That could be obtained through this patch:
>
> https://github.com/apollo13/django/compare/ticket15089
>
> or maybe like what is done for the custom User model.
>

What's the use case here? What additional data do you want to track?


> There's some more features for full multi tenancy listed here
> https://code.djangoproject.com/ticket/15089#comment:36
>
> but the above will suffice for my usage so i will not dig into it.
>

Broadly speaking the approach you've described in #17802 makes sense to me
- that is, find somewhere where the request is needed, and make sure it's
available. I haven't dug in to the full consequences of introducing the
request where you've put it, but the broad strokes look right.

Unfortunately, we're not going to rush into something here - once we add or
change an API, we need to support it, and we are committing to not changing
it - so before we make any changes, we need to make sure we're not backing
ourselves into a corner. That means solving the general problem (or at
least having an idea how we would address the general problem), not just
one small part of the problem.

The other approach that you haven't made mention of - Use a different sites
app altogether. Django's sites module isn't well designed for true multi
tenancy of the type that you're describing. However, it's also a contrib
app -- so it's entirely optional, and also replaceable. If you have a
specific set of requirements for multi tenancy, then write your own
third-party app to implement those changes, and use it.


> So to summarize with just a couple of patches to the site framework and a
> dozen lines middleware one could build a basic django multi tenancy site.
>
> How can I help to have this in 1.7?
>

Also - Not Going to Happen. 1.7 beta has been released, so the window for
new features is closed. The best you can hope for at this point is for
inclusion in Django 1.8.

Yours
Russ Magee %-)

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

Re: On django multi tenancy

[patrick . dobbs]

> Short version - it doesn't matter what pretty name you put on it, a thread 
> local is a global variable. We teach first year programmers not to use 
> globals, so why would we introduce them to Django as a core framework idea?
>

Aren't database connections thread local in Django?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/45f45c00-eb44-43fc-b8b8-7a085ae344a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On django multi tenancy

[Michael Manfre]

On Wed, Apr 2, 2014 at 7:42 PM,  wrote:

>
> Short version - it doesn't matter what pretty name you put on it, a thread
>> local is a global variable. We teach first year programmers not to use
>> globals, so why would we introduce them to Django as a core framework idea?
>>
>
> Aren't database connections thread local in Django?
>

Yes, but that is due to PEP 249 [1] allowing database drivers to not have
thread safe connections. Django didn't have much of a choice about making
connections thread local. Well, there was the choice to not follow PEP 249,
but that would have been a foolish decision.

Regards,
Michael Manfre

[1] http://legacy.python.org/dev/peps/pep-0249/#threadsafety

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

Re: On django multi tenancy

[Russell Keith-Magee]

On Thu, Apr 3, 2014 at 7:42 AM,  wrote:

>
> Short version - it doesn't matter what pretty name you put on it, a thread
>> local is a global variable. We teach first year programmers not to use
>> globals, so why would we introduce them to Django as a core framework idea?
>>
>
> Aren't database connections thread local in Django?
>

I'm tempted to just say "Please, go read the old threads", because I'm not
going to be saying anything new here, and I'm running the risk of giving
oxygen to a debate that I have exactly zero interest in revisiting.

Yes, Django does use threadlocals in a limited number of places.

However:
 1) They're used as a mechanism of last resort
 2) They are exposed through APIs that hide this fact as much as possible.
 3) They're consistently sources of development pain for the core team, for
all the reasons that global variables cause problems generally.

Putting request into threadlocals would mean putting active user state into
a thread local, and encouraging users to interact with that user state as a
global variable that "just exists".

It also ignores the fact that in many situations - for example, worker
scripts - there is no such thing as a "current request".

If I had a magic wand and could eliminate all the uses of threadlocals in
our current codebase, I would. However, it's not that simple, for a
combination of backwards compatibility reasons, and practical reasons. I'm
yet to see an argument for thread local requests that doesn't boil down to
"I don't want to pass a request object around as an argument."

For the record, I'll reiterate my *Strong* -1 against threadlocal requests
(if it wasn't already obvious).

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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-sUhECmgq7gQY3F%2B%2Be87YiMpyOSsxK-1uxTfxuag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.