Feature Request: Provide an option to disable static files caching during development

[Bharat Chauhan]

Hello,

I recently opened a ticket (#33148 
) but it was closed as 
duplicate of (#32891 ) which 
itself is marked "wontfix".

The reasoning provided by Carlton Gibson for this is:

> *I don't think this is the right approach. As far as I can see the 
browser behaviour is correct and as desired, s**erving static assets from 
the browser cache when possible.*

At least while DEBUG is True, I see no harm in setting `Cache-Control: 
max-age=0` header.

This will allow browsers to cache the files while forcing them to 
revalidate cache using the If-Modified-Since header. This way, Django can 
serve updated files if they get modified or return a 304 response in which 
case browsers will use the cached file (conforming to Carlton's comment 
about using browser cache when possible).

This will aid in development as we now have to open the browser's network 
tab and disable the cache to refresh static files. In Mobile, disabling 
cache is not possible, so we have to test in Incognito Mode. It's a 
frustrating development experience.

Thank you.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/36582e40-8969-4ed7-a4ae-ed6214e64fdfn%40googlegroups.com.

Re: Feature Request: Provide an option to disable static files caching during development

[laym...@gmail.com]

I'm +1 on this.

In my experience teaching Django at university, this always confuses 
students: "why are my changes not reflected in the browser?"

Having static files caching disabled when DEBUG=True would be very useful. 
Thanks for bringing this up!

Sage

On Monday, 27 September 2021 at 20:17:35 UTC+7 Bharat Chauhan wrote:

> Hello,
>
> I recently opened a ticket (#33148 
> ) but it was closed as 
> duplicate of (#32891 ) which 
> itself is marked "wontfix".
>
> The reasoning provided by Carlton Gibson for this is:
>
> > *I don't think this is the right approach. As far as I can see the 
> browser behaviour is correct and as desired, s**erving static assets from 
> the browser cache when possible.*
>
> At least while DEBUG is True, I see no harm in setting `Cache-Control: 
> max-age=0` header.
>
> This will allow browsers to cache the files while forcing them to 
> revalidate cache using the If-Modified-Since header. This way, Django can 
> serve updated files if they get modified or return a 304 response in which 
> case browsers will use the cached file (conforming to Carlton's comment 
> about using browser cache when possible).
>
> This will aid in development as we now have to open the browser's network 
> tab and disable the cache to refresh static files. In Mobile, disabling 
> cache is not possible, so we have to test in Incognito Mode. It's a 
> frustrating development experience.
>
> Thank you.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f84a796f-f2be-4846-bd35-e9640c77e550n%40googlegroups.com.

Re: Add warning or prohibit module level queries?

[laym...@gmail.com]

+1, I've had people raising issues that were caused by this. They were 
using a query to provide a model field's default value.

On Sunday, 26 September 2021 at 02:06:21 UTC+7 Adam Johnson wrote:

> I noticed I've continued to encounter this problem in code review 
> relatively frequently, so I made a ticket: 
> https://groups.google.com/g/django-developers/c/7JwWatLfP44/ . Tim then 
> pointed me back to this discussion.
>
> I'm happy to implement Tim's suggestion of a RuntimeWarning followed by 
> deprecation if it doesn't cause many problems. Just checking here if anyone 
> would be against the idea.
>
> On Thursday, February 25, 2016 at 10:42:07 PM UTC cur...@tinbrain.net 
> wrote:
>
>> +1 
>>
>> At the very least we need to provide better feedback or errors to help 
>> isolate _where_ this is happening. 
>>
>> I've helped quite a number of people on IRC with this problem... 
>> firstly, people aren't understanding _what_ the problem is, but also 
>> discerning where it's happening is often quite difficult, even with a 
>> full traceback. 
>>
>> -- 
>> C 
>>
>>
>> On 26/02/16 04:29, Tim Graham wrote: 
>> > Simon proposed [0]: "I wonder if we should prevent django.db from 
>> > executing queries until django.apps.apps.ready or at least issue a 
>> > RuntimeWarning. We would have to go through deprecation but I'm pretty 
>> > sure this would uncover a lot of existing application bugs and prevent 
>> > future ones. This is related to #25454 
>> >  [1] and probably a large 
>> > number of closed tickets." 
>> > 
>> > 
>> > We have this restriction in some places, for example: "Executing 
>> > database queries with the ORM at import time in models modules will 
>> also 
>> > trigger this exception. The ORM cannot function properly until all 
>> > models are available." 
>> > 
>> > We also have a warning about using the ORM in AppConfig.ready(): 
>> > "Although you can access model classes as described above, avoid 
>> > interacting with the database in your |ready()| implementation. This 
>> > includes model methods that execute queries (|save()|, |delete()|, 
>> > manager methods etc.), and also raw SQL queries via 
>> > |django.db.connection|. Your |ready()| method will run during startup 
>> of 
>> > every management command. For example, even though the test database 
>> > configuration is separate from the production settings, |manage.py 
>> test| 
>> > would still execute some queries against your *production* database!" 
>> > 
>> > There's also a warning in the testing docs: "Finding data from your 
>> > production database when running tests? If your code attempts to access 
>> > the database when its modules are compiled, this will occur /before/ 
>> the 
>> > test database is set up, with potentially unexpected results. For 
>> > example, if you have a database query in module-level code and a real 
>> > database exists, production data could pollute your tests. /It is a bad 
>> > idea to have such import-time database queries in your code/ anyway - 
>> > rewrite your code so that it doesn’t do this. This also applies to 
>> > customized implementations of |ready()|." 
>> > 
>> > What do you think? Prohibiting such queries might be too strict at this 
>> > point as I guess some users might rely on them. I suppose warnings 
>> could 
>> > be selectively silenced as/if needed. We could start with a warning and 
>> > ask users to let us know if they believe they have a legitimate usage. 
>> > If we don't hear anything, we could proceed with the deprecation. 
>> > 
>> > Related tickets: 
>> > 
>> > [0] https://code.djangoproject.com/ticket/26273 
>> > [1] https://code.djangoproject.com/ticket/25454 
>> > 
>> > -- 
>> > 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-develop...@googlegroups.com 
>> > . 
>> > To post to this group, send email to django-d...@googlegroups.com 
>> > . 
>> > 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/7f41ba58-09ed-4f78-b5ce-be6d7d5a6fc7%40googlegroups.com
>>  
>> > <
>> https://groups.google.com/d/msgid/django-developers/7f41ba58-09ed-4f78-b5ce-be6d7d5a6fc7%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>  
>>
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/m