On 19 helmi, 02:31, Carl Meyer wrote:
> On 02/18/2013 02:27 PM, Aymeric Augustin wrote:
>
> > Problem #1: Is it worth re-executing the connection setup at the beginning
> > of
> > every request?
>
> > The connection setup varies widely between backends:
> > - SQLite: none
> > -
> > PostgreSQL:ht
On 19 févr. 2013, at 11:04, Anssi Kääriäinen wrote:
> Maybe we need another setting for what to do in request.start. It does
> seem somewhat likely that users could do SET SEARCH_PATH in middleware
> to support multitenant setups for example, and expect that set to go
> away when connection is cl
On 19 helmi, 12:20, Aymeric Augustin
wrote:
> On 19 févr. 2013, at 11:04, Anssi Kääriäinen wrote:
>
> > Maybe we need another setting for what to do in request.start. It does
> > seem somewhat likely that users could do SET SEARCH_PATH in middleware
> > to support multitenant setups for example,
On 02/19/2013 03:04 AM, Anssi Kääriäinen wrote:
> I hope this discussion is about what to do at request finish/start
> time.
>
> I am very strongly opposed to anything where Django suddenly changes
> connections underneath you. At request finish/start this is OK (you
> should expect new connection
Hi,
On Monday 18 February 2013, Ioan Alexandru Cucu wrote:
>
> If I'm running a select_for_update statement in a multidb environment that
> uses a read-only slave database
>
Why does this operation make sense?
Why would you select-for-update if you don't intend to update? Or does
updating on a
We've issued several security releases today. Details are in the blog post:
https://www.djangoproject.com/weblog/2013/feb/19/security/
We recommend everyone carefully read this one, as it has an
end-user-visible change requiring action beyond simply upgrading your
Django package.
--
You receive
Hi,
I was just about to tell someone on IRC that Django's
backwards-compatibility policy only applies to documented methods and
attributes (which is how I'd always understood it), but when I actually
went to look at the documented policy it isn't as clear as I'd hoped :/
https://docs.djangoprojec
I agree, backwards compatibility for an API should be opt-in (via
documenting), not opt-out (via naming).
Alex
On Tue, Feb 19, 2013 at 1:56 PM, Carl Meyer wrote:
> Hi,
>
> I was just about to tell someone on IRC that Django's
> backwards-compatibility policy only applies to documented methods
On Tue, 2013-02-19 at 14:50 -0600, James Bennett wrote:
> We've issued several security releases today. Details are in the blog
post:
>
> https://www.djangoproject.com/weblog/2013/feb/19/security/
>
> We recommend everyone carefully read this one, as it has an
> end-user-visible change requiring
Hi Nick,
On 02/19/2013 03:32 PM, Nick Phillips wrote:
> I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
> do, it seems rather problematic. In particular, that host verification
> is apparently turned off while DEBUG is True or while testing.
>
> Surely this makes it impossi
On 19 févr. 2013, at 22:56, Carl Meyer wrote:
> I was just about to tell someone on IRC that Django's
> backwards-compatibility policy only applies to documented methods and
> attributes (which is how I'd always understood it), but when I actually
> went to look at the documented policy it isn't a
On Wed, Feb 20, 2013 at 5:56 AM, Carl Meyer wrote:
> Hi,
>
> I was just about to tell someone on IRC that Django's
> backwards-compatibility policy only applies to documented methods and
> attributes (which is how I'd always understood it), but when I actually
> went to look at the documented pol
Hi folks,
I downloaded Django 1.4.4 this evening and after switching to it started
getting the following error on my CentOS 6.3 / Python 2.6 based system:
ImportError: Bad magic number in
/usr/lib/python2.6/site-packages/django/contrib/sessions/management/__init__.pyc
After confirming my md5su
Ah it looks like there's already a ticket on it:
https://code.djangoproject.com/ticket/19858
On Tuesday, February 19, 2013 7:12:52 PM UTC-8, Nick Popoff wrote:
>
> Hi folks,
>
> I downloaded Django 1.4.4 this evening and after switching to it started
> getting the following error on my CentOS 6
On Tue, Feb 19, 2013 at 10:12 PM, Nick Popoff wrote:
> In the case of ./contrib/sessions/management/__init__.pyc an __init__.py
> is not provided.
>
> Is it possible compiled 2.7 .pyc files were included instead of .py files
> by mistake?
>
The .pyc files were certainly included by mistake, the
One question: does this proposal include some way of specifying a maxiumum
number of outstanding connections to the database from a single process?
Looked but didn't see it in the pull request. In my experience, most
PostgreSQL instances don't have a whole lot of breathing room in terms of
th
I don't really see what point such an option would serve. This is *not a
connection pool*. Currently Django uses one open connection per thread,
this simple keeps them open between requests. That means before: you needed
O(concurrent threads) connections, now you need O(total active threads)
connec
Hi,
Well that's what I'm saying. It doesn't make any sense.
By default, django runs the select_for_update query on the 'for read'
database instead of running it on the 'for write' database.
In order to make my code not to break, I need to explicitly tell django
that I want the query to run on t
Hi Ioan,
I'd need to dig into the code to be 100% certain, but what you've described
seems plausible, and the fix looks like it's going in the right direction.
A ticket is certainly called for.
As for the patch -- it needs tests :-)
Django's test suite has support for testing multiple-database s
19 matches
Mail list logo
