Re: More multi-database plumbing (WAS Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings)

[Alex Gaynor]

On Fri, Mar 13, 2009 at 12:26 AM, Adrian Holovaty wrote:

>
> On Thu, Mar 12, 2009 at 11:53 PM, Alex Gaynor 
> wrote:
> > Great, since we've moved so quickly on improving our plumbing for this
> there
> > was one other idea I wanted to put forth(since I believe it needs to
> happen
> > for any multidb implementation).  In terms of plumbing the cornerstone of
> my
> > multidb proposal is the addition of a django.db.connections object which
> > lazily returns connections by subscripting based on a DATABASES option
> which
> > is a dictionary of dictionaries.  I think we could add support for this
> > relatively easily, with full backwards compatibility.  However, we only
> have
> > 1 week until feature freeze so I wouldn't want to proceed with this
> unless
> > everyone was completely comfortable with that proposed API, but I figured
> > I'd bring it up since we have moved so quickly on these past bits.
>
> Yeah, a collection of connections (called django.db.connections or
> whatever) is one of the next logical steps for multi-database support.
> But for the time being, that's 90% just a pretty API and only 10%
> plumbing. It can be worked-around completely without changing Django
> internals. (I've got a DATABASES setting in my application, along with
> a custom manager that checks the setting to get connection-specific
> parameters -- code very similar to
> http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
> )
>
> Regarding the one-week-until-feature-freeze reality -- we haven't
> *hit* the feature freeze yet, so it seems like it's still fair game,
> but this *would* be a bigger change than the previous few, so it'd be
> worth discussing the pluses and minuses.
>
> A bigger issue (one that requires plumbing, unless I'm completely
> missing something) is to get django/db/transaction.py to be aware of
> the multiple connections. All of the functions in there deal directly
> with the global connection, and I don't immediately see an easy way to
> refactor things to work on separate connections. Any ideas? Alex, have
> you addressed this in the Grand Proposal of yours? :-)
>
> Adrian
>
> >
>
My "nuts and bolts" document(which I've alluded to several times but haven't
actually posted since my laptop has been dead :( ) has fixing up the
transcation stuff, specifically I put it after we had a basic public API,
but before we get into the more complicated bits in terms of the
implementation schedule.  That being said it looks like all the states there
is handled in a series of dictionaries keyed on thread id, so my instinct
would be to turn those into dictionaries of dictionaries keyed on thread id
and connection alias respectively and have each of the relevant functions
take an extra parameter, which defaults to None, which should be a list of
db aliases that the op should be preformed on(None indicicating all dbs),
this preserves backwards compatibility and makes sense in terms of the
common usage, for example at the end of a request I want to commit against
all dbs but when I create a savepoint I only actually create that on 1 db.

Having said all that I don't think that's stuff that necessarily needs to
happen when we add the connections object, since as it is our transaction
stuff doesn't come into play when someone grabs a cursor themselves with
even our single DB(this is filed as a bug and I imagine will get fixed for
1.1).

If no one has any seroius objections other than it's a sort of big addition
with not a ton of time and we don't want to mess of the public/private API
bridge I'll probably start coding something up tommorow.


Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

More multi-database plumbing (WAS Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings)

[Adrian Holovaty]

On Thu, Mar 12, 2009 at 11:53 PM, Alex Gaynor  wrote:
> Great, since we've moved so quickly on improving our plumbing for this there
> was one other idea I wanted to put forth(since I believe it needs to happen
> for any multidb implementation).  In terms of plumbing the cornerstone of my
> multidb proposal is the addition of a django.db.connections object which
> lazily returns connections by subscripting based on a DATABASES option which
> is a dictionary of dictionaries.  I think we could add support for this
> relatively easily, with full backwards compatibility.  However, we only have
> 1 week until feature freeze so I wouldn't want to proceed with this unless
> everyone was completely comfortable with that proposed API, but I figured
> I'd bring it up since we have moved so quickly on these past bits.

Yeah, a collection of connections (called django.db.connections or
whatever) is one of the next logical steps for multi-database support.
But for the time being, that's 90% just a pretty API and only 10%
plumbing. It can be worked-around completely without changing Django
internals. (I've got a DATABASES setting in my application, along with
a custom manager that checks the setting to get connection-specific
parameters -- code very similar to
http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
)

Regarding the one-week-until-feature-freeze reality -- we haven't
*hit* the feature freeze yet, so it seems like it's still fair game,
but this *would* be a bigger change than the previous few, so it'd be
worth discussing the pluses and minuses.

A bigger issue (one that requires plumbing, unless I'm completely
missing something) is to get django/db/transaction.py to be aware of
the multiple connections. All of the functions in there deal directly
with the global connection, and I don't immediately see an easy way to
refactor things to work on separate connections. Any ideas? Alex, have
you addressed this in the Grand Proposal of yours? :-)

Adrian

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

[Alex Gaynor]

On Thu, Mar 12, 2009 at 11:42 PM, Adrian Holovaty wrote:

>
> On Thu, Mar 12, 2009 at 7:59 PM, Alex Gaynor 
> wrote:
> >> I've created a ticket here:
> >>
> >>http://code.djangoproject.com/ticket/10487
> >>
> >> If anybody (Alex?) wants to code up a patch, I'll get it in ASAP.
> >>
> >> Adrian
> >
> > I've gone ahead and uploaded a patch(at this rate they'll be nothing to
> do
> > over the summer :) ).
>
> Thanks, Alex. I've committed it in
> http://code.djangoproject.com/changeset/10045 .
>
> Adrian
>
> >
>
Great, since we've moved so quickly on improving our plumbing for this there
was one other idea I wanted to put forth(since I believe it needs to happen
for any multidb implementation).  In terms of plumbing the cornerstone of my
multidb proposal is the addition of a django.db.connections object which
lazily returns connections by subscripting based on a DATABASES option which
is a dictionary of dictionaries.  I think we could add support for this
relatively easily, with full backwards compatibility.  However, we only have
1 week until feature freeze so I wouldn't want to proceed with this unless
everyone was completely comfortable with that proposed API, but I figured
I'd bring it up since we have moved so quickly on these past bits.

Any thoughts are welcome,
Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: guidelines for docs/misc/distributions.txt

[Tim Graham]

I've created the following ticket to address the issue along with an
initial patch:
http://code.djangoproject.com/ticket/10424

The new page for distribution specific installation instructions can
be found:
http://code.djangoproject.com/wiki/Distributions

Hope that helps,
Tim

On Mar 5, 7:40 am, Russell Keith-Magee  wrote:
> On Thu, Mar 5, 2009 at 9:13 AM, Malcolm Tredinnick
>
>
>
>  wrote:
>
> > On Wed, 2009-03-04 at 09:28 -0800, Tim Graham wrote:
> >> Hi,
>
> >>http://docs.djangoproject.com/en/dev/misc/distributions/is rather out-
> >> of-date with respective to the versions of Django that are shipping
> >> with each OS.  A summary of tickets that are currently accepted:
>
> >> 8417 - request to add ArchLinux
> >> 8497 - request to add OpenSolaris
> >> 9606 - request to add OpenSUSE
> >> 9667 - suggestion to replace package versions with links to up-to-date
> >> searches on the distributions page
> >> 9911 - request to update Debian version
> >> 10319 - new instructions for MacPorts
>
> >> I think the suggestion to link to a search on each distribution's
> >> website makes the most sense,
>
> > I'd actually prefer to have much less than that. We say something like
> > "if you're using Linux or a Unix installation, such as OpenSolaris,
> > check with your distributor to see if they already package Django." If
> > you're using a Linux distro and don't know how to find out if a package
> > is available, then now is a good time to learn anyway.
>
> > Keeping even a list of links to most recent packages up to date is going
> > to be onerous. There are over 200 Linux distributions. Where do we draw
> > the line? By favouring nobody special, it's easier.
>
> > Then we definitely can have a wiki page of links to the latest packages
> > and all 200 Linux distros plus Sun plus SCO plus IBM can all update it
> > themselves.
>
> > We spend a lot of time, unfortunately, doing OS-specific support and it
> > takes time away from things that are much more in scope for Django. We
> > can't really avoid doing something special for Mac and Windows, since
> > their general third-party packaging support is so woeful as to be almost
> > non-existent. Linux and Unix distros have generally solved that problem,
> > to the point of providing standard tools to allow package searches and
> > installs, so let's rely on them as much as we can.
>
> +1. This is something we can very easily defer to the wiki and the community.
>
> There are two parts required here -
>
> 1) The wiki needs to be updated, adding an index page for installation
> instructions, plus linking to individual pages for the install
> instructions for each distro),
>
> 2) A first draft of the text to put on the installation instructions page.
>
> This should also be opened as a new ticket, unifying (and deprecating)
> the other tickets you mentioned.
>
> Yours
> Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

[Alex Gaynor]

On Thu, Mar 12, 2009 at 7:04 PM, Adrian Holovaty wrote:

>
> On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov  wrote:
> > Maybe let's go a bit further towards pool of db connections and wrap a
> > bunch of lines importing backend into some function that depends on
> > engine argument?
> > And later call it with settings.DATABASE_ENGINE to import default
> backend.
> >
> >
> http://code.djangoproject.com/browser/django/trunk/django/db/__init__.py?rev=10026
> > Lines 12-38.
>
> Yes, good idea, Yuri! It would be nice to encapsulate the logic of
> loading the appropriate Django database backend class from
> django.db.backends based on a given backend name.
>
> I've created a ticket here:
>
>http://code.djangoproject.com/ticket/10487
>
> If anybody (Alex?) wants to code up a patch, I'll get it in ASAP.
>
> Adrian
>
> >
>
I've gone ahead and uploaded a patch(at this rate they'll be nothing to do
over the summer :) ).

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

[Adrian Holovaty]

On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov  wrote:
> Maybe let's go a bit further towards pool of db connections and wrap a
> bunch of lines importing backend into some function that depends on
> engine argument?
> And later call it with settings.DATABASE_ENGINE to import default backend.
>
> http://code.djangoproject.com/browser/django/trunk/django/db/__init__.py?rev=10026
> Lines 12-38.

Yes, good idea, Yuri! It would be nice to encapsulate the logic of
loading the appropriate Django database backend class from
django.db.backends based on a given backend name.

I've created a ticket here:

http://code.djangoproject.com/ticket/10487

If anybody (Alex?) wants to code up a patch, I'll get it in ASAP.

Adrian

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

[Alex Gaynor]

On Thu, Mar 12, 2009 at 1:26 PM, Yuri Baburov  wrote:

>
> On Thu, Mar 12, 2009 at 11:44 AM, James Bennett 
> wrote:
> >
> > On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov 
> wrote:
> >> Maybe let's go a bit further towards pool of db connections and wrap a
> >> bunch of lines importing backend into some function that depends on
> >> engine argument?
> >
> > FWIW I'm still strongly of the opinion that database connection
> > pooling does not belong in an ORM like Django's.
> Dear James,
> But I didn't tell whether connection pooling should belong to Django
> ORM or not! And neither I told how do I understand "connection
> pooling"...
>
> Let's just wrap those lines into a function! :)
>
> Adrian suggested a new way to write function get_db_wrapper in comments at
> http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
>
> But why not have a method get_db_engine(engine_name) in the Django ORM
> code?
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com
>
> >
>
Yuri,

FWIW that's on my list of stuff that would happen for multi-db support, but
if someone wants to file a ticket and write up a patch(or I can) now that's
certainly fine as it's really just code cleanup.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

[Yuri Baburov]

On Thu, Mar 12, 2009 at 11:44 AM, James Bennett  wrote:
>
> On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov  wrote:
>> Maybe let's go a bit further towards pool of db connections and wrap a
>> bunch of lines importing backend into some function that depends on
>> engine argument?
>
> FWIW I'm still strongly of the opinion that database connection
> pooling does not belong in an ORM like Django's.
Dear James,
But I didn't tell whether connection pooling should belong to Django
ORM or not! And neither I told how do I understand "connection
pooling"...

Let's just wrap those lines into a function! :)

Adrian suggested a new way to write function get_db_wrapper in comments at
http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/

But why not have a method get_db_engine(engine_name) in the Django ORM code?

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Call for review: #689 - REMOTE_USER authentication

[Jacob Kaplan-Moss]

Hey Gary --

Looks good to me. My only comment would be that I'd move the docs into
howto/ instead of topics/. Other than that, I'm happy with this code
as is. Malcolm's pickier than I am, though, so you might want to see
what he's got to say :P

Jacob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Unified access to response.context in test client (follow-up)

[Julien Phalip]

On Mar 12, 11:10 pm, Russell Keith-Magee 
wrote:
> On Thu, Mar 12, 2009 at 8:31 PM, Julien Phalip  wrote:
>
> > On Mar 12, 9:30 pm, Russell Keith-Magee 
> > wrote:
> >> On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip  wrote:
>
> >> > Hi,
>
> >> > A few months ago James raised the issue on this list:
> >> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> >> > Basically, the type for the test client's response context is
> >> > inconsistent. Sometimes it's a dictionary and other times it's a list
> >> > of dictionaries, depending on whether or not the tested page was built
> >> > with a hierarchy of templates.
>
> >> > I don't think this has been fixed yet. Could someone confirm? If it
> >> > hasn't, then does it have a chance to make it into 1.1? I haven't been
> >> > able to find any ticket for it, should one be created?
>
> >> The status of this issue hasn't changed. It hasn't been fixed. There
> >> isn't an existing ticket to the best of my knowledge. As Jacob noted
> >> the last time you asked, this is a relatively small change, so if a
> >> suitably complete patch were to materialize out of the ether, it would
> >> probably find itself in trunk for v1.1.
>
> > Thanks Russ. I'm keen to have a go at it during the upcoming sprints.
> > You and Jacob say it's a small change. Could you please give a hint on
> > what that is? Just so that I have something to start with and so I can
> > pull off the groundwork more quickly.
>
> James (Bennett) pretty much described what needs to happen - it hinges
> on adding __getitem__ operator for the context object which is
> sensitive to whether the context is being subscripted by integer or by
> string. i.e.,
>
> request.context[3] will get the third context in the stack
> request.context['foo'] will try to find the key 'foo' in the context.
>
> James gave a bit more detail in his post.

Makes perfect sense. I created a ticket for it (#10482) and will start
with a patch soon.

Cheers,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Unified access to response.context in test client (follow-up)

[Russell Keith-Magee]

On Thu, Mar 12, 2009 at 8:31 PM, Julien Phalip  wrote:
>
> On Mar 12, 9:30 pm, Russell Keith-Magee 
> wrote:
>> On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip  wrote:
>>
>> > Hi,
>>
>> > A few months ago James raised the issue on this list:
>> >http://groups.google.com/group/django-developers/browse_thread/thread...
>>
>> > Basically, the type for the test client's response context is
>> > inconsistent. Sometimes it's a dictionary and other times it's a list
>> > of dictionaries, depending on whether or not the tested page was built
>> > with a hierarchy of templates.
>>
>> > I don't think this has been fixed yet. Could someone confirm? If it
>> > hasn't, then does it have a chance to make it into 1.1? I haven't been
>> > able to find any ticket for it, should one be created?
>>
>> The status of this issue hasn't changed. It hasn't been fixed. There
>> isn't an existing ticket to the best of my knowledge. As Jacob noted
>> the last time you asked, this is a relatively small change, so if a
>> suitably complete patch were to materialize out of the ether, it would
>> probably find itself in trunk for v1.1.
>
> Thanks Russ. I'm keen to have a go at it during the upcoming sprints.
> You and Jacob say it's a small change. Could you please give a hint on
> what that is? Just so that I have something to start with and so I can
> pull off the groundwork more quickly.

James (Bennett) pretty much described what needs to happen - it hinges
on adding __getitem__ operator for the context object which is
sensitive to whether the context is being subscripted by integer or by
string. i.e.,

request.context[3] will get the third context in the stack
request.context['foo'] will try to find the key 'foo' in the context.

James gave a bit more detail in his post.

Yours
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Unified access to response.context in test client (follow-up)

[Julien Phalip]

On Mar 12, 9:30 pm, Russell Keith-Magee 
wrote:
> On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip  wrote:
>
> > Hi,
>
> > A few months ago James raised the issue on this list:
> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> > Basically, the type for the test client's response context is
> > inconsistent. Sometimes it's a dictionary and other times it's a list
> > of dictionaries, depending on whether or not the tested page was built
> > with a hierarchy of templates.
>
> > I don't think this has been fixed yet. Could someone confirm? If it
> > hasn't, then does it have a chance to make it into 1.1? I haven't been
> > able to find any ticket for it, should one be created?
>
> The status of this issue hasn't changed. It hasn't been fixed. There
> isn't an existing ticket to the best of my knowledge. As Jacob noted
> the last time you asked, this is a relatively small change, so if a
> suitably complete patch were to materialize out of the ether, it would
> probably find itself in trunk for v1.1.

Thanks Russ. I'm keen to have a go at it during the upcoming sprints.
You and Jacob say it's a small change. Could you please give a hint on
what that is? Just so that I have something to start with and so I can
pull off the groundwork more quickly.

Cheers,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Unified access to response.context in test client (follow-up)

[Russell Keith-Magee]

On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip  wrote:
>
> Hi,
>
> A few months ago James raised the issue on this list:
> http://groups.google.com/group/django-developers/browse_thread/thread/1b10084ea969141e
>
> Basically, the type for the test client's response context is
> inconsistent. Sometimes it's a dictionary and other times it's a list
> of dictionaries, depending on whether or not the tested page was built
> with a hierarchy of templates.
>
> I don't think this has been fixed yet. Could someone confirm? If it
> hasn't, then does it have a chance to make it into 1.1? I haven't been
> able to find any ticket for it, should one be created?

The status of this issue hasn't changed. It hasn't been fixed. There
isn't an existing ticket to the best of my knowledge. As Jacob noted
the last time you asked, this is a relatively small change, so if a
suitably complete patch were to materialize out of the ether, it would
probably find itself in trunk for v1.1.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Unified access to response.context in test client (follow-up)

[Julien Phalip]

Hi,

A few months ago James raised the issue on this list:
http://groups.google.com/group/django-developers/browse_thread/thread/1b10084ea969141e

Basically, the type for the test client's response context is
inconsistent. Sometimes it's a dictionary and other times it's a list
of dictionaries, depending on whether or not the tested page was built
with a hierarchy of templates.

I don't think this has been fixed yet. Could someone confirm? If it
hasn't, then does it have a chance to make it into 1.1? I haven't been
able to find any ticket for it, should one be created?

Cheers,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Call for review: #689 - REMOTE_USER authentication

[Malcolm Tredinnick]

Hey Gary,

On Thu, 2009-03-12 at 01:40 -0500, Gary Wilson Jr. wrote:
> Just posted an updated patch:
> 
> http://code.djangoproject.com/attachment/ticket/689/689.4.diff

If nobody gets to it beforehand, I'll give this a serious look tomorrow.

Cheers,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Call for review: #689 - REMOTE_USER authentication

[Gary Wilson Jr.]

Just posted an updated patch:

http://code.djangoproject.com/attachment/ticket/689/689.4.diff

Gary

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---