I use --liveserver for a slightly different case and had missed the
original conversation. I'm not sure if mine justifies the code either, but
for consideration:
My company's authentication layer includes a homebrewed google oauth2
endpoint. I've added localhost:8000 to the valid redirect_uris
This is what I wanted to know. I am willing to take on starting this DEP,
with the caveat I've not done one before, and it will almost certainly
require many revisions.
On Tuesday, 8 November 2016 15:32:48 UTC, Marc Tamlyn wrote:
>
> I have fed a lot into this discussion in person and on Slack.
I didn't realise there's a difference. Personally, I think response.items() is
better. Although it would be much nicer if headers could be accessed in the
same way in HttpRequest and HttpResponse, so a ticket you posted earlier is
quite relevant. In my opinion 'HEADERS' property (or lower-case '
Sorry, I didn't read closely enough. I'm not sure about this. Do you really
want the raw _headers dict or something like response.items()?
>>> response.items()
dict_values([('foo', 'bar'), ('Content-Type', 'text/html; charset=utf-8')])
>>> response._headers
{'content-type': ('Content-Type', 'tex
I'm not sure if anything could or should be done, but I noticed a warning
in the documentation that Aymeric added:
"If you’re synchronizing content types to more than one database, be aware
that their primary keys may not match across databases. This may result in
data corruption or data loss.
Take a look at the commit that made the removal:
https://github.com/django/django/commit/81cdcb66bc74a0768d13f0e18872d46739028e64
--liverserver was only a shortcut for setting the
DJANGO_LIVE_TEST_SERVER_ADDRESS environment variable, so that could be done
without a command line argument, however
Given ticket is about HttpRequest headers, I was writing about HttpResponse. Am
I missing something?
> On 8 Nov 2016, at 19:56, Tim Graham wrote:
>
> Here's an accepted ticket for the idea:
> https://code.djangoproject.com/ticket/20147
>
> It looks like there's rough consensus but a complete
Here's an accepted ticket for the idea:
https://code.djangoproject.com/ticket/20147
It looks like there's rough consensus but a complete patch hasn't been
provided.
On Tuesday, November 8, 2016 at 11:04:53 AM UTC-5, roboslone wrote:
>
> Hi!
>
> Is there a reason why HttpResponse doesn't have p
Hi!
Is there a reason why HttpResponse doesn't have public 'headers' property?
I want to log all response headers in tests and don't want to access private
'_headers' property.
Implementation is very simple and will prevent user from changing actual
headers (if that was intended in the first pl
I have fed a lot into this discussion in person and on Slack. I don't
understand all the ins and outs completely, but I feel that the situation
is sufficiently complex enough that we need to consider it all together.
The code was certainly very challenging when I tried to make a UUID field
use a DB
On Tue, Nov 8, 2016 at 12:34 PM, Patryk Zawadzki
wrote:
> I've just hit another problem related to custom fields.
>
> Currently migrations contain information about "rich" fields. If you use a
> custom field type, the migration code will currently import your field type
> from its Python module.
We were having a discussion on this matter on the Django under the Hood
Slack channel, and there's a design decision that I think I can't take by
myself.
There are 2 related subject : the "readonly" part and the "auto_refresh"
part. Readonly means that the database won't try to write, autorefre
I've just hit another problem related to custom fields.
Currently migrations contain information about "rich" fields. If you use a
custom field type, the migration code will currently import your field type
from its Python module. This is highly problematic in case either the code
moves or you lat
Hi guys,
Currently i'm debugging our server problem, reaching down to the Django
code.
In django/db/transaction.py:267
I found `connection.set_autocommit(True)` statement if the connection is
not in atomic block.
Anyone who can explain me why it's setting auto_commit to True especially
in
14 matches
Mail list logo
