#11675: [patch] Support new memcached wrapper pylibmc
---------------------------------------------+------------------------------
Reporter: pipp...@yahoo.co.jp | Owner: otherjacob
Status: assigned | Milestone: 1.2
Component: Cache system | Version: SVN
Resolution: | Keywords: cache pylibmc
memcached.py
Stage: Design decision needed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------
Changes (by russellm):
* stage: Accepted => Design decision needed
Comment:
Erm... there's a test, but no actual fix?
Also - I'm not completely sold on either approach. Specifying a module
name in the CACHE_BACKEND setting is a neat idea - provided there is some
sort of guarantee that the API for a python memcache backend is always the
same. From first inspection, this isn't true (set_many vs set_multi).
Subclassing seems like overkill, given that there is a limited number of
support classes out there.
Another option that hasn't been floated is to allow pylibmc:// definitions
that point to a cache.memcache.PyLibMemcache implementation; that is, we
do the subclassing, so end users don't have to.
Also - given that cmemcache is clearly deprecated, so we should also
deprecate it's use.
--
Ticket URL: <http://code.djangoproject.com/ticket/11675#comment:6>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
