> I don't think what you are suggesting would be necessary. Stream-capable
> middleware could avoid having to handle both cases by simply wrapping
> response.content with a new iterator in all cases, if they want to.
> Non-streaming responses can still be iterated. They just have fewer
> iterat
Hi Ryan,
I don't think what you are suggesting would be necessary. Stream-capable
middleware could avoid having to handle both cases by simply wrapping
response.content with a new iterator in all cases, if they want
to. Non-streaming responses can still be iterated. They just have fewer
iterat
On Thu, Aug 23, 2012 at 10:16 PM, sergzach wrote:
> The question about databases.
>
> Do I understand correctly that if we create a MyUser class (as in your
> example) then extra fields (e.g. date_of_birth) will be stored in the same
> table of a database with inherited fields (from AbstractBaseUs
> In 1.7 we could raise a loud exception when stream_content=True and
> response.content is accessed directly. Middleware can do nothing if they
> don't care about or need to worry about streaming responses. If they are
> capable of functioning with a streaming response, they can check
> respon
I have updated the patch on my GitHub repository after some discussion on
IRC with Anssi. The patch applies on master again now, it consumes
generator content on access instead of on assignment, and raises a
PendingDeprecationWarning if you create an HttpResponse with
stream_content=True and th
On 23 elo, 15:51, Anssi Kääriäinen wrote:
> My current feeling about the options is that this is getting
> complex... So, as-simple-as-can-be solution:
> - Add a flag to the response which tells if the response is
> streaming or not. You can set this in response's.__init__. We might be
> able to
The question about databases.
Do I understand correctly that if we create a MyUser class (as in your
example) then extra fields (e.g. date_of_birth) will be stored in the same
table of a database with inherited fields (from AbstractBaseUser)?
> ===
> from django.db import models
>
> from dja
Hi all,
I'm not really ready to post this as a bug, please help me correct any
possible misunderstandings before I do so.
I was gently pushed towards the future url template tag due to my
screen filling up with DeprecationWarnings
There isn't a whole lot of documentation about the new url tag. T
On 23 elo, 12:52, Tai Lee wrote:
> After discussion with akaarai and mYk on IRC, I have two updated proposals.
>
> OPTION 6:
>
> 1. Consume `HttpResponse.content` on first access, so that it can be read
> multiple times and eliminate the current buggy behaviour (e.g.
> `response.content != respons
After discussion with akaarai and mYk on IRC, I have two updated proposals.
OPTION 6:
1. Consume `HttpResponse.content` on first access, so that it can be read
multiple times and eliminate the current buggy behaviour (e.g.
`response.content != response.content`) when a generator is passed in a
10 matches
Mail list logo
