Re: A generic cache decorator around low level cache api

['Adam Johnson' via Django developers (Contributions to Django itself)]

I'm not sure I quite understand your proposal. Are you suggesting a
decorator that caches the results of every queryset that is resolved within
the decorated function?

If so, I'm not sure how useful it would be. First, if a single query is
problematic, there’s normally a way to optimize it within the database -
for example, a materialized view allows you to “cache” query results and
recompute them in the background. Second, QuerySets are lazy, so it could
be surprising to decorate a function that returns a QuerySet that is not
yet resolved.

On Wed, Aug 24, 2022 at 3:49 PM suayip uzulmez  wrote:

> Usually, I need to construct a simple cache pipeline to optimize database
> access using low-level cache API (django.core.cache).
>
> I think we could use a decorator as such to ease this process:
>
> cached_context(key, *, timeout, cache)
>
> I know higher-level utilities exist such as cache_page, however I think
> the decorator above provides more granularity over what to cache. For
> example, I usually need such decorator in model methods where I do some
> database aggregation operations based on the instance.
>
> What do you think?
>
> --
> 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/facbcfa8-2404-4dc6-b56d-eb0f25ba491cn%40googlegroups.com
> 
> .
>

-- 
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/CAMyDDM3jh_tHOLfxggk68114kSS3qk3i0vBsd-kvqcp1WXCr7Q%40mail.gmail.com.

Re: A generic cache decorator around low level cache api

[suayip uzulmez]

It doesn't necessarily have to be a QuerySet; any function or  method that 
takes some processing time could be decorated (e.g., an external call to an 
API). My aim is to reduce this code:

def do_some_processing():
cache_key = "key"

if cached_value := cache.get(cache_key):
return cached_value

fresh_value = do_some_computing()
cache.set(cached_value, fresh_value, 30)
return fresh_value

to this:

@cached_context("key", timeout=30)
def do_some_processing():
return do_some_computing()


AFAIK cache.set evaluates QuerySets, how would that be a problem?.
26 Ağustos 2022 Cuma tarihinde saat 12:24:39 UTC+3 itibarıyla Adam Johnson 
şunları yazdı:

> I'm not sure I quite understand your proposal. Are you suggesting a 
> decorator that caches the results of every queryset that is resolved within 
> the decorated function?
>
> If so, I'm not sure how useful it would be. First, if a single query is 
> problematic, there’s normally a way to optimize it within the database - 
> for example, a materialized view allows you to “cache” query results and 
> recompute them in the background. Second, QuerySets are lazy, so it could 
> be surprising to decorate a function that returns a QuerySet that is not 
> yet resolved.
>
> On Wed, Aug 24, 2022 at 3:49 PM suayip uzulmez  wrote:
>
>> Usually, I need to construct a simple cache pipeline to optimize database 
>> access using low-level cache API (django.core.cache).
>>
>> I think we could use a decorator as such to ease this process:
>>
>> cached_context(key, *, timeout, cache)
>>
>> I know higher-level utilities exist such as cache_page, however I think 
>> the decorator above provides more granularity over what to cache. For 
>> example, I usually need such decorator in model methods where I do some 
>> database aggregation operations based on the instance.
>>
>> What do you think?
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/facbcfa8-2404-4dc6-b56d-eb0f25ba491cn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/3e380893-2211-47a9-bb6c-71e626459a87n%40googlegroups.com.

ModelForm field autofocus

[Christian González]

Hi devs,

I often come across the problem that I want to have a field take the 
autofocus in Django.


Especially when dealing with high abstraction when using ModelForms, 
this is barely possible using templates, so the only way is to create a 
ModelForm subclass and tell it to put the autofocus into that field.


This is very cumbersome, as the view itself IMHO is the better place to 
decide where the focus should be - especially when using GenericViews. 
This is very convenient.


After trying a few StackExchange solutions, I wrote a simple Mixin that 
can be applied to a GenericView:


   class PersonUpdateView(UpdateView):
    model = Person
    fields = ["first_name", "last_name"]
    autofocus = "first_name"

The code is simple:

   class AutoFocusMixin: """Put the 'autofocus' attribute to a given
   field""" autofocus = None def get_form(self, form_class=None):form =
   super().get_form(form_class) if self.autofocus in form.fields:
   form.fields[self.autofocus].widget.attrs.update({"autofocus": True})
   return form

Is this worth including in Django core?

Christian

--
Dr. Christian González
https://nerdocs.at

--
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/8c839dc6-1ed5-6910-e9e2-c18cb9d90123%40nerdocs.at.