Re: LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

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

Re: New deferred loading implementation (Was: [Review Request] Added support for database delegated fields (like AutoField))

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.

Re: HttpResponse.headers public property

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

Re: HttpResponse.headers public property

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',

Re: Uniform content type tables with multiple databases

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

Re: LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

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,

Re: HttpResponse.headers public property

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

Re: HttpResponse.headers public property

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

HttpResponse.headers public property

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

Re: New deferred loading implementation (Was: [Review Request] Added support for database delegated fields (like AutoField))

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

Re: Rethinking migrations

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 >

Re: New deferred loading implementation (Was: [Review Request] Added support for database delegated fields (like AutoField))

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,

Re: Rethinking migrations

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

Django transaction: set_autocommit

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