Hello, Until now, this feature request was always declined. As a consequence, every user who wants Redis has to choose between django-redis and django-redis-cache. Considering that Redis must be the most popular cache backend these days, I'm in favor of providing an off-the-shelf solution in Django itself. It's unlikely to be a large maintenance burden. It will "just work".
I don't know if factoring out common functionality between the memcached and redis backends will really make them easier to maintain. We'll end up with three modules (key-value, memcached and redis), which will be more complicated than two. If we had three similar backends, that would be a strong argument for factoring out common functionality. With only two backends, it may not be worth the complexity. To move this forwards, my suggestion would be to write a DEP, to flesh out the rationale for a built-in solution, and to focus on the breadth of functionality the built-in backend would support. My preference would be a basic set of features, like the other cache backends. I believe that's what django-redis-cache does. This will leave room for third-party packages like django-redis to provide more advanced features. To give a concrete example, like other cache and database backends, a redis backend could provide persistent connections but not implement a connection pool. Until now Django has left the management of connection pools to third-party packages. Best regards, -- Aymeric. > On 17 Jun 2019, at 17:11, Dulmandakh Sukhbaatar <[email protected]> wrote: > > Hello, > > I would like to work on Redis support in core, and I would like to discuss > proper solution for that. > > Redis is getting so popular and almost every modern backend stack uses it > someway, therefore I think that supporting it as a cache backend in core > would make Django more appealing. A solution I'm proposing is to extract base > KV backend from current Memcached and extend it for both Memcached and Redis, > and this won't add many new code to the core. Also we'll have base class for > KV storage backends. > > Thanks. > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/3a506133-f08a-4d25-a9c5-099aae3722d8%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/3a506133-f08a-4d25-a9c5-099aae3722d8%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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 [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/F93AED93-32FC-4BF4-BDA7-48B4A76A8314%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
