Deserialization with get_by_natural_key

I'm having trouble loading external data for a model that uses a ContentType foreign key. I'm using a manager in the models, like the docs say. Unfortunately, although the docs talk about the importance of a get_by_natural_key method on a ContentType foreign key, it then launches into a different

Sane defaults for Startapp and Startproject

Hey guys! So I've just written a blog post about getting started with Django, http://gun.io/blog/python-for-the-web/, and many of the things here just make me think, 'why doesn't it just do that by default?' Here's some of what I propose. I'm not suggesting this be a canonical list of features by

Re: Sane defaults for Startapp and Startproject

How would you guys feel about a manage.py startexample which would create an example application? A simple, templated hello world with an example model and an example view and an example template? R On Oct 20, 4:50 pm, Aymeric Augustin wrote: > On 20 oct. 2011, at 22:22, Carl Meyer wrote: > > >

Re: Sane defaults for Startapp and Startproject

Having an example project to fork/fiddle with in the documentation is a fair compromise. svn co http://code.djangoproject.com/svn/django/trunk/ django-example ? R On Oct 21, 2:22 pm, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Rich, > > On 1

Announcing Django-Zappa - Serverless Django on AWS Lambda + API Gateway

tch?v=plUrbPN0xc8&feature=youtu.be And see the code here: https://github.com/Miserlou/django-zappa Comments, questions and pull requests are welcome! It seems quite performant already, but I bet there are ways that we can improve Django to work better on Lambda. Enjoy, Rich Jones -- You rece

Re: Announcing Django-Zappa - Serverless Django on AWS Lambda + API Gateway

Yes, it calls is in a WSGI mode. I've found that response time is around 80-100ms. On Monday, February 8, 2016 at 5:02:00 PM UTC+1, Florian Apolloner wrote: > > Hi Rich, > > to quote from your blog post: > >> the server is created *after* the HTTP request comes in t

Improving django.setup() and app loading performance

(Originally posted this as a ticket, but we can have discussion here and leave the ticket for just more specific discussion.) I imagine that this is an area that hasn't really been given much consideration with regards to optimization, because it is

Re: Improving django.setup() and app loading performance

That might be true in theory.. but in practice? Do any of the core/contrib/top100 apps actually depend on loading orders? I've never encountered that problem before, but I don't know. It seems like we could easily get a 10x performance improvement by doing this in parallel by default, and have

Re: Improving django.setup() and app loading performance

@Aymeric > In my opinion, the first concrete step would be to measure how much time is spent executing Django code rather than importing Python modules. You can find a complete profile of a Django request as it goes through the complete request/response loop here: https://github.com/Miserlou/dj

Re: Improving django.setup() and app loading performance

Hey all! Let me clarify a few of the terms here and describe a bit how Django operates in this context. "Serverless" in this contexts means "without any permanent infrastructure". The server is created _after_ the request comes in, and it dies once the response is returned. The means that we n

Re: Improving django.setup() and app loading performance

oving this. Suggestions always welcome! R On Monday, February 29, 2016 at 11:26:17 PM UTC+1, Rich Jones wrote: > > Hey all! > > Let me clarify a few of the terms here and describe a bit how Django > operates in this context. > > "Serverless" in this c

Re: Improving django.setup() and app loading performance

thread, since this > looks more like a response to a zappa forum :) > > > > El lunes, 29 de febrero de 2016, 19:34:16 (UTC-3), Rich Jones escribió: >> >> For those who are still following along, these are the lines in question: >> >> >> https:

Re: Improving django.setup() and app loading performance

As I suspected, moving setup() outside of the handler had a negligible effect - in fact the test showed a slight drop in performance. :( Testing from httping. From Berlin to US-East-1: Before: --- https://arb9clq9k9.execute-api.us-east-1.amazonaws.com/unicode/json_example/ ping statistics ---

Re: Improving django.setup() and app loading performance

That certainly could have something to do with it - there isn't very much transparency about how API Gateway works. It's super new and pretty janky, TBQH. However, I think that the behavior describing is not what's expected - the caching seems to be for the assets of the whole environment, not o

Re: Improving django.setup() and app loading performance

Hm. This is the downside of cloud services - we cannot look under the hood. Since I think that since this is something we _want_ cached, and because it will make the function being executed shorter in length - it is a good code decision to make. Thank you for the idea! However, it looks like the

Re: Improving django.setup() and app loading performance

Ah, interesting! Thanks for tracking that down. In chat we basically discovered that the intercontinental latency and shoddy wifi connections were responsible for a lot of the confusion. Testing from a US-based fiber connection, we got results of ~40ms in both scenarios. --- https://arb9clq9

unique_together does not work as expected with nullable fields

I just got bitten by this today, finding a duplicate row where I didn't expect one. I haven't been able to find an existing Django bug. It's a popular topic on stack overflow: http://stackoverflow.com/questions/17510261/django-unique-together-constraint-failure http://dba.stackexchange.com/que

Re: unique_together does not work as expected with nullable fields

On Friday, April 29, 2016 at 12:51:31 AM UTC-7, Florian Apolloner wrote: > > > I am not against a note in the docs, but I find the fact that nulls are > not "unique" and can exist in an index more than once very useful (fwiw > ordering after a column with null can also be interesting across >

Re: unique_together does not work as expected with nullable fields

On Friday, April 29, 2016 at 2:16:45 AM UTC-7, Anssi Kääriäinen wrote: > > If you really, really want an unique index that allows just a single > value, you might want to try unique index on (a, b, c) where c is not > null, and another unique index on (a, b) where c is null. That might > give

Re: unique_together does not work as expected with nullable fields

On Friday, April 29, 2016 at 11:00:37 AM UTC-7, Aymeric Augustin wrote: > > Hi Rich, > > On 29 Apr 2016, at 19:52, Rich Rauenzahn > > wrote: > > > I see now that I need to provide a sentinel value -- > BOO=True,VAL=, or manually create additional unique indexes.

failure to load fixtures during unit tests

as if sometimes the fixtures are installed in different order each time, which makes me think of some dict.keys() that doesn't return the same order every time. Rich -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to D

Re: failure to load fixtures during unit tests

t really looks like the _save_table() method in Model is trying to insert a row even though the object has already been restored/inserted. At the moment, I'm reproducing it with the auth.User Model. I'm getting closer to seeing what is happening I have a user, rich, which expects t

Re: failure to load fixtures during unit tests

classes, or if that is standard. Rich -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubsc