Hello Bobby,

> On 4 Jan 2017, at 22:25, Bobby Mozumder <[email protected]> wrote:
> 
> It’s actually called once on app startup during DB connection via a Signal.

Unless I missed something, since the development server creates a new 
connection to the database for each request — Python’s threaded socket server 
creates a new thread for each connection and database connections are thread 
local in Django — prepared statements will be refreshed for each request. So I 
don’t think you need autoreloading here.

> (This whole process helps speed up the view response generation times.  I can 
> generate a full page in about 4ms, and that includes GZip.)

Off topic, but I’m jealous…

<rant>

I still believe we should stop maintaining an autoreloader as soon as possible. 
Django’s autoreloader is annoyingly slow, highly inefficient, moderately well 
designed, and a gigantic pain to maintain. I’m more scared of 
django.utils.autoreload than of django.db.models.related before it was cleaned 
up.

I wish one day someone will take the time to write a good autoreloading dev 
server based on watchman. This would solve the problem discussed here because 
watchman watches all files in the current directory. The correct way to do this 
is to throw away the current design and start from scratch.

Watchman is smart enough to wait until you’ve finished a git operation to 
trigger a reload. Once such polished tech has become available, trying to 
compete with a thread that checks the mtime of all known files every second 
isn’t funny anymore. In fact it’s just sad.

</rant>

While I don’t care much about django.utils.autoreloader because I want to kill 
it, I’m reluctant to add public APIs such as the proposed setting, which may 
not make sense with an hypothetical better autoreloader.

I’m -0 on the change. I could move to +0 if I understood why the use case 
described here requires watching additional files.

Best regards,

-- 
Aymeric.

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BAAB82B3-974C-4240-B9C6-E81F04D9604F%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to