Re: Making key_prefix callable for more flexible caching
Are there any plans to work on this? I can pick it up as I already implemented this functionality into own project. What is the process to working on the new features? On Sunday, 23 January 2022 at 12:37:52 UTC+2 Adam Johnson wrote: > Hi Tobias > > I think it's also worth mentioning your blog post, in which you explain > (to yourself) how to currently achieve dynamic keys: > https://rixx.de/blog/how-django-s-page-cache-works/ . It's a lot of work. > > The closure of #11269 does seem like an oversight, since the > CACHE_MIDDLEWARE_KEY_PREFIX setting doesn't support dynamic prefixes. > > I am in favour of allowing callable prefixes. It seems like a small > feature with great utility. > > Thanks, > > Adam > > On Sat, 22 Jan 2022 at 15:37, Tobias Kunze wrote: > >> Hi all, >> >> after mostly caching via external tools or manually for years, I've been >> trying out Django's built-in caching recently, and have ran into an issue >> that >> I believe could improve the use cases of `cache_page` a lot: >> >> `cache_page`/`CacheMiddleware` take an optional `key_prefix` argument as a >> string, falling back to `settings.CACHE_MIDDLEWARE_KEY_PREFIX`. >> >> If this argument could be a callable (getting the current request as >> argument), it would be much easier to cache different versions of the >> page, >> for example for users with different access rights, or to make sure newer >> changes are reflected by including a version or timestamp in the cache >> key. >> >> This change was proposed, uhm, 13 years ago, and was closed when the >> key_prefix became a site-wide setting. Any arguments for/against >> re-opening? >> >> https://code.djangoproject.com/ticket/11269 >> >> Additionally, for several of my use cases it would have been very neat to >> be >> able to determine the cache key myself, which is currently generated >> fairly >> deep into the caching stack based on the prefix, the request and so on. >> While >> that's a good default, it makes it harder to interact with the cache from >> outside the request-response cycle for the view being cached. >> (But that's a bigger ask, because there's less existing infrastructure to >> pass >> down a changed key function – I'd be pretty happy with just a dynamic >> prefix.) >> >> Best, >> Tobias >> -- >> Tobias Kunze / rixx (er/he) >> >> -- >> 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/20220122153731.4beyiyepuahiprgu%40cordelia.localdomain >> . >> > -- 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/0ffd5069-a3bb-4312-a2ef-787813c48fd9n%40googlegroups.com.
Re: Making key_prefix callable for more flexible caching
I opened https://code.djangoproject.com/ticket/33604 On Wednesday, 23 March 2022 at 01:49:18 UTC+2 Adam Johnson wrote: > It doesn't look like Tobias has done anything. I would say open a new > ticket referencing this discussion, and then open your PR against that. All > the how-to's are in the docs: > https://docs.djangoproject.com/en/dev/internals/contributing/ > > On Mon, Mar 21, 2022 at 6:07 PM Alexandru M. wrote: > >> Are there any plans to work on this? I can pick it up as I already >> implemented this functionality into own project. What is the process to >> working on the new features? >> >> On Sunday, 23 January 2022 at 12:37:52 UTC+2 Adam Johnson wrote: >> >>> Hi Tobias >>> >>> I think it's also worth mentioning your blog post, in which you explain >>> (to yourself) how to currently achieve dynamic keys: >>> https://rixx.de/blog/how-django-s-page-cache-works/ . It's a lot of >>> work. >>> >>> The closure of #11269 does seem like an oversight, since the >>> CACHE_MIDDLEWARE_KEY_PREFIX setting doesn't support dynamic prefixes. >>> >>> I am in favour of allowing callable prefixes. It seems like a small >>> feature with great utility. >>> >>> Thanks, >>> >>> Adam >>> >>> On Sat, 22 Jan 2022 at 15:37, Tobias Kunze wrote: >>> >>>> Hi all, >>>> >>>> after mostly caching via external tools or manually for years, I've been >>>> trying out Django's built-in caching recently, and have ran into an >>>> issue that >>>> I believe could improve the use cases of `cache_page` a lot: >>>> >>>> `cache_page`/`CacheMiddleware` take an optional `key_prefix` argument >>>> as a >>>> string, falling back to `settings.CACHE_MIDDLEWARE_KEY_PREFIX`. >>>> >>>> If this argument could be a callable (getting the current request as >>>> argument), it would be much easier to cache different versions of the >>>> page, >>>> for example for users with different access rights, or to make sure >>>> newer >>>> changes are reflected by including a version or timestamp in the cache >>>> key. >>>> >>>> This change was proposed, uhm, 13 years ago, and was closed when the >>>> key_prefix became a site-wide setting. Any arguments for/against >>>> re-opening? >>>> >>>> https://code.djangoproject.com/ticket/11269 >>>> >>>> Additionally, for several of my use cases it would have been very neat >>>> to be >>>> able to determine the cache key myself, which is currently generated >>>> fairly >>>> deep into the caching stack based on the prefix, the request and so on. >>>> While >>>> that's a good default, it makes it harder to interact with the cache >>>> from >>>> outside the request-response cycle for the view being cached. >>>> (But that's a bigger ask, because there's less existing infrastructure >>>> to pass >>>> down a changed key function – I'd be pretty happy with just a dynamic >>>> prefix.) >>>> >>>> Best, >>>> Tobias >>>> -- >>>> Tobias Kunze / rixx (er/he) >>>> >>>> -- >>>> 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/20220122153731.4beyiyepuahiprgu%40cordelia.localdomain >>>> . >>>> >>> -- >> 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/0ffd5069-a3bb-4312-a2ef-787813c48fd9n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/0ffd5069-a3bb-4312-a2ef-787813c48fd9n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/178caaf9-b128-44d6-b8e6-95cf0b8bce15n%40googlegroups.com.
Re: Probable Bug, foreign key to a database view.
Does it behave the way you're expecting it to behave if you declare field as models.CharField(max_length=4, primary_key=True)? On Saturday, 26 March 2022 at 15:45:39 UTC+2 sandeep...@gmail.com wrote: > class View(models.Model): > field = models.CharField(max_length=4) > class Meta: > managed=False > db_table = 'view' #database view > > class Child(models.Model): > view = models.ForeignKey(View, on_delete=models.CASCADE, > to_field='field', db_constraint=False) > > makemigrations on above will have the *view* field of type integer while > it should be varcher(4) > > This is my first post to the forum. Please inform if something is amiss. > > 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/a08d95ee-7707-4ef6-bf7a-df77b0b81726n%40googlegroups.com.
