On Aug 4, 1:33 pm, Byron wrote:
> What are your thoughts on adding these implementations to core?
I think that the callable key function would fit well in core, and
debatably the flavor, version, and hashing stuff could fit well in
core too. I don't really think that the thundering herd protectio
Hi Eric - I took a look at django-newcache and I like the overall
design. The whole thought behind my patch was a simple way to provide
a global cache prefix since I had ran into key clashes among my
projects (equivalent to your 'FLAVOR' setting). Your solution provides
a much more flexible and ext
The most flexible way is to be able to specify a callable that runs on
each cache key before it is sent to the server. Then it's just up to
Django to provide a sensible default callable, but people could
override it to provide one which matches their own requirements. This
is what I do in django-
On 8/4/2010 10:57 AM, Jacob Kaplan-Moss wrote:
On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote:
Updated the patch http://code.djangoproject.com/ticket/13795
* Have you considered supporting "versioning" of keys to help with cache
invalidation? Eric Florenzano has been doing some inte
Thanks Jacob. I personally don't think the CACHE_MIDDLEWARE_KEY_PREFIX
is necessary anymore. I suggest removing it, but I would imagine it
would have to be deprecated for the next release then removed in 1.4?
> As a rule, you should avoid evaluating settings at import time, so in
> this case you'd
On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote:
> Updated the patch http://code.djangoproject.com/ticket/13795
Looks good. A couple of questions/comments:
* Is there a reason to keep CACHE_MIDDLEWARE_KEY_PREFIX around? I don't
quite see the point of a separate setting, so unless you can think of
Updated the patch http://code.djangoproject.com/ticket/13795
On Jun 23, 11:12 am, Russell Keith-Magee
wrote:
> On Sun, Jun 20, 2010 at 6:16 AM, Byron wrote:
> > Yes I agree. I never quite understood why the
> > CACHE_MIDDLEWARE_KEY_PREFIX was implemented, but not at the lower
> > level (did thec
On Sun, Jun 20, 2010 at 6:16 AM, Byron wrote:
> Yes I agree. I never quite understood why the
> CACHE_MIDDLEWARE_KEY_PREFIX was implemented, but not at the lower
> level (did the cache API become available after the middleware
> caching?). Of course a custom backend can be written, but then there
Yes I agree. I never quite understood why the
CACHE_MIDDLEWARE_KEY_PREFIX was implemented, but not at the lower
level (did the cache API become available after the middleware
caching?). Of course a custom backend can be written, but then there
would need to be a different one for each backend type.
This is a good feature and I also have my custom cache backend with
project-level key prefixes. It was easy to implement and doesn't
require changes in django core. But if this backend is in django core
(that's a good idea) then some other changes should be done. There
will be 2 similar options aft
Opened a ticket and added my patch.. http://code.djangoproject.com/ticket/13795
On Jun 15, 7:15 pm, Giuseppe Ciotta wrote:
> On Wed, Jun 16, 2010 at 1:04 AM, Giuseppe Ciotta wrote:
> > On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck wrote:
> >> On Sun, Jun 13, 2010 at 7:18 AM, lenz wrote:
> >>>
On Wed, Jun 16, 2010 at 1:04 AM, Giuseppe Ciotta wrote:
> On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck wrote:
>> On Sun, Jun 13, 2010 at 7:18 AM, lenz wrote:
>>> Could you share your code with us?
>>> Thanks you!
>>
>> This might help:
>> http://gist.github.com/425403
>
> I have some similar c
On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck wrote:
> On Sun, Jun 13, 2010 at 7:18 AM, lenz wrote:
>> Could you share your code with us?
>> Thanks you!
>
> This might help:
> http://gist.github.com/425403
I have some similar code here: http://gist.github.com/439868
It might be better because
On Sun, Jun 13, 2010 at 7:18 AM, lenz wrote:
> Could you share your code with us?
> Thanks you!
This might help:
http://gist.github.com/425403
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-dev
Could you share your code with us?
Thanks you!
Lenz
On 2 Jun., 01:14, Gabriel Hurley wrote:
> Personally, I solved this by writing a wrapper around
> django.utils.cachethat can be dropped in transparently. It was a
> really simple matter to have it take acacheprefix(in my case from
> settings.py
On Jun 2, 9:51 am, batiste wrote:
> What about the problem that you can, in theory, use the same
> application several time (several instance) within the same project?
There is a Google Summer of Code Project
http://code.djangoproject.com/wiki/SummerOfCode2010
that will hopefully take care of th
What about the problem that you can, in theory, use the same
application several time (several instance) within the same project?
I don't have a real use-case, but I have heard people doing it.
http://groups.google.com/group/django-users/browse_thread/thread/076f31a1a5479676/8d5f2e0f8f1e1957
Bat
Yea, I definitely agree that it is a simple solution. I think the the
fact that the setting is optional and would not break any existing
code, it should be included since it "feels" like a common case... we
shall leave it up to the core devs to determine this.
On Jun 1, 7:14 pm, Gabriel Hurley wr
Personally, I solved this by writing a wrapper around
django.utils.cache that can be dropped in transparently. It was a
really simple matter to have it take a cache prefix (in my case from
settings.py) and pass that into the original functions.
It's a pretty easy fix if the core team agrees that i
I ran into a seemingly common problem with cache key conflicts between
two projects that both share an app and the same memcache instance. I
would imagine that being able to optionally set a PROJECT_CACHE_PREFIX
that is prepended to every key when setting/getting would be a nice
transparent way of
20 matches
Mail list logo
