sprint-related django.core.cache thoughts/questions

2 views
Skip to first unread message

pbx

unread,
Dec 1, 2007, 10:44:21 AM12/1/07
to Django developers
A while ago I was picking through the cache system and found a few
things that seemed like they could use cleanup. I'm interested in
hearing thoughts on which of these might be worth pursuing, whether
today or later.

* The "simple" backend seems obsolete. The newer "locmem" is
functionally equivalent for the user, but is suitable for deployment
as well as development. Should "simple" be removed? This might allow
refactoring of the backend code to simplify its inheritance structure.

* "cull_percentage" is called "cull_frequency" inside the code;
neither is a great name, but the second is better. Worth changing?

* A documentation question: Does "manage.py createcachetable" create
an indexed table? if so, we don't need to repeat their admonition
about making sure the table's indexed.

* Should the "file" backend's _file_for_key method be rewritten to use
hashes instead of cleaned-up strings? It fails to correctly handle an
empty string, which is a valid string and dictionary key otherwise.

In any case, looking forward to a few hours of Django hacking today...

pb

--
Paul Bissex <p...@e-scribe.com>
Northampton, MA 01060

Jacob Kaplan-Moss

unread,
Dec 1, 2007, 11:53:09 AM12/1/07
to Django developers
On Dec 1, 9:44 am, pbx <paul.bis...@gmail.com> wrote:
> * The "simple" backend seems obsolete. The newer "locmem" is
> functionally equivalent for the user, but is suitable for deployment
> as well as development. Should "simple" be removed? This might allow
> refactoring of the backend code to simplify its inheritance structure.

Yeah, that sounds like a good idea. I'd like to see a patch that
aliased "simple" to "locmem" and raised a DeprecationWarning. We'll
then remove simple in 1.0.

> * "cull_percentage" is called "cull_frequency" inside the code;
> neither is a great name, but the second is better. Worth changing?

Ugh, I hate to break existing code for a change from a crappy name to
a slightly better one. I think it's not worth it unless someone can
come up with a *really* good, intuitive name.

> * A documentation question: Does "manage.py createcachetable" create
> an indexed table? if so, we don't need to repeat their admonition
> about making sure the table's indexed.

I *think* it does, but you should double-check. It should, so a patch
to make it do so would be great.

> * Should the "file" backend's _file_for_key method be rewritten to use
> hashes instead of cleaned-up strings? It fails to correctly handle an
> empty string, which is a valid string and dictionary key otherwise.

Yes - hashes are better. Even better would be to do a bit of
subdirectory creation based on hashes to prevent problems on
filesystems that don't like millions of files in the same directory.
Something like "6f/1e/d002ab5595859014ebf0951522d9.pickle" or
whatever.

Thanks!

Jacob

pbx

unread,
Dec 1, 2007, 4:12:53 PM12/1/07
to Django developers
> I'd like to see a patch that
> aliased "simple" to "locmem" and raised a DeprecationWarning. We'll
> then remove simple in 1.0.

Done: http://code.djangoproject.com/ticket/6086

> > * Should the "file" backend's _file_for_key method be rewritten to use
> > hashes instead of cleaned-up strings? It fails to correctly handle an
> > empty string, which is a valid string and dictionary key otherwise.
>
> Yes - hashes are better. Even better would be to do a bit of
> subdirectory creation based on hashes to prevent problems on
> filesystems that don't like millions of files in the same directory.
> Something like "6f/1e/d002ab5595859014ebf0951522d9.pickle" or
> whatever.

We've got a patch in progress for this, which we will either attach to
#6086 or to a new ticket which we'll add a pointer to from #6086.

Thanks for the quick assessment!

pb

pbx

unread,
Dec 5, 2007, 5:29:19 PM12/5/07
to Django developers
Just wanted to note for posterity that the first and fourth items in
the list that started this thread have been taken care of. Thanks
again to David and Brian for diving in.

> * The "simple" backend seems obsolete. The newer "locmem" is
> functionally equivalent for the user, but is suitable for deployment
> as well as development. Should "simple" be removed? This might allow
> refactoring of the backend code to simplify its inheritance structure.

http://code.djangoproject.com/changeset/6822

> * Should the "file" backend's _file_for_key method be rewritten to use
> hashes instead of cleaned-up strings? It fails to correctly handle an
> empty string, which is a valid string and dictionary key otherwise.

http://code.djangoproject.com/changeset/6887

Reply all
Reply to author
Forward
0 new messages